AW: AW: ant java versions
> > Strange that there are deprecated warnings even on 1.3 ... > > But the build works :) > > I'm pretty sure that the tests don't though :( Java 1.3 ... build ... build test [junit] Testcase: testHasErrorInCase(org.apache.tools.ant.util.FileUtilsTest): FAILED [junit] null [junit] junit.framework.AssertionFailedError [junit] at junit.framework.Assert.fail(Assert.java:47) [junit] at junit.framework.Assert.assertTrue(Assert.java:20) [junit] at junit.framework.Assert.assertTrue(Assert.java:27) [junit] at org.apache.tools.ant.util.FileUtilsTest.testHasErrorInCase(FileUtilsTest .java:582) [au:antunit] Build File: C:\ant\svn-repository\ant\core\src\tests\antunit\taskdefs\echoxml-test.x ml [au:antunit] Tests run: 4, Failures: 0, Errors: 1, Time elapsed: 0,047 sec [au:antunit] Target: test-ns caused an ERROR [au:antunit]at line 47, column 72 [au:antunit]Message: Problem: failed to create task or type antlib:org.apache.ant.antunit:assertResourceContains [au:antunit] Cause: The name is undefined. [au:antunit] Action: Check the spelling. [au:antunit] Action: Check that any custom tasks/types have been declared. [au:antunit] Action: Check that any / declarations have taken place. [au:antunit] [au:antunit] The definitions in the namespace antlib:org.apache.ant.antunit are: [au:antunit] antunit [au:antunit] assertPropertySet [au:antunit] assertLogContains [au:antunit] assertPropertyEquals [au:antunit] logcapturer [au:antunit] logcontent [au:antunit] logcontains [au:antunit] assertDestIsUptodate [au:antunit] assertFilesMatch [au:antunit] assertFalse [au:antunit] assertFileExists [au:antunit] assertFileDoesntExist [au:antunit] assertMatches [au:antunit] expectfailure [au:antunit] assertFilesDiffer [au:antunit] assertEquals [au:antunit] xmllistener [au:antunit] assertPropertyContains [au:antunit] assertDestIsOutofdate [au:antunit] assertReferenceIsType [au:antunit] assertLogDoesntContain [au:antunit] assertReferenceSet [au:antunit] plainlistener [au:antunit] assertTrue [au:antunit] [au:antunit]took 0,016 sec [au:antunit] Build File: C:\ant\svn-repository\ant\core\src\tests\antunit\taskdefs\optional\scrip t\scriptdef-test.xml [au:antunit] Tests run: 6, Failures: 0, Errors: 6, Time elapsed: 0,047 sec [au:antunit] Target: testMixedResources caused an ERROR [au:antunit]at line 78, column 9 [au:antunit]Message: Unable to load a script engine manager (org.apache.bsf.BSFManager or javax.script.ScriptEngineManager) [au:antunit]took 0,015 sec [au:antunit] Target: testInline caused an ERROR [au:antunit]at line 39, column 9 [au:antunit]Message: Unable to load a script engine manager (org.apache.bsf.BSFManager or javax.script.ScriptEngineManager) [au:antunit]took 0 sec [au:antunit] Target: testStringResourceRef caused an ERROR [au:antunit]at line 51, column 9 [au:antunit]Message: Unable to load a script engine manager (org.apache.bsf.BSFManager or javax.script.ScriptEngineManager) [au:antunit]took 0 sec [au:antunit] Target: testPropertyResource caused an ERROR [au:antunit]at line 70, column 9 [au:antunit]Message: Unable to load a script engine manager (org.apache.bsf.BSFManager or javax.script.ScriptEngineManager) [au:antunit]took 0 sec [au:antunit] Target: testStringResource caused an ERROR [au:antunit]at line 44, column 9 [au:antunit]Message: Unable to load a script engine manager (org.apache.bsf.BSFManager or javax.script.ScriptEngineManager) [au:antunit]took 0 sec [au:antunit] Target: testStringResourceInline caused an ERROR [au:antunit]at line 59, column 9 [au:antunit]Message: Unable to load a script engine manager (org.apache.bsf.BSFManager or javax.script.ScriptEngineManager) [au:antunit]took 0 sec [au:antunit] Build File: C:\ant\svn-repository\ant\core\src\tests\antunit\taskdefs\optional\unix\ symlink-test.xml [au:antunit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0,031 sec [au:antunit] Build File: C:\ant\svn-repository\ant\core\src\tests\antunit\taskdefs\propertyhelper -test.xml [au:antunit] Tests run: 0, Failures: 0, Errors: 6, Time elapsed: 0,031 sec [au:antunit] caused an ERROR [au:antunit]at line 6, column 48 [au:antunit]Message: Unable to load the BSF script engine manager (org.apache.bsf.BSFManager) [au:antunit]took 0,016 sec [au:antunit] caused an ERROR [au:antunit]at line 6, column 48 [au:antunit]Message: Unable to load the BSF script engine manager (org.apache.bsf.BSFManager) [au:antunit]took 0,032 sec [au:antunit] caused an ERROR [au:antunit]at line 6, column 48 [au:antunit]Message: Unable to load the BSF script engine manager (org.apache.bsf.BSFManager) [au:antunit]took 0,032 sec [au:antunit] caused an ERROR [au:antunit]at line 6, column 48 [au:antunit]Message: Unable to load the BSF script engine manager (org.apache.bsf.BSFManager) [au:antunit
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
On Jan 16, 2008 8:54 AM, Gilles Scokart <[EMAIL PROTECTED]> wrote: > 2008/1/15, Louis Tribble <[EMAIL PROTECTED]>: > > > > Dominique Devienne wrote: > > > On 1/15/08, Louis Tribble <[EMAIL PROTECTED]> wrote: > > > > > >> Consequently, my main comment (apologies if I missed it in the > thread) > > >> is that any magic target overriding feature needs to balanced by > > >> a target locking feature, for at least two reasons: (1) the integrity > > of > > >> the > > >> build depends on certain chunks of script (typically in the > xxx-default > > >> targets) always being invoked and (2) nobody can understand and > > >> manage a build of 500 modules if modules do their own thing even for > > >> basic tasks like compiling and creating jars. > > >> > > > > > > This is interesting. So you want some kind of "final" keyword for a > > > target, to allow controlled customization only, right? Basically the > > > template method pattern, with an immutable public target, and only > > > limited customization. > > > > > Right. In fact, we were very conscious of applying design > > patterns to the build system. > > > > > >> A corollary is that if I were to base this system on the hypothesized > > >> Ant-supplied system, I expect I would need to customize quite a bit, > > >> but I would not want to expose most of that customizability to the > > >> modules. (Perhaps that is something like what Gilles was thinking > > >> when he mentioned two levels of customization?) > > >> > > > > > > That's where I'm confused. You want to be able to customize in some > > > places, but not in others??? I don't quite follow what you mean here. > > > > > Sorry if I wasn't clear. Xavier was suggesting (in part) a set > > of reusable build scripts. To be useful, those scripts need to > > be customizable in a variety of ways, which led to the > > discussion of super and before/after and so on. I was noting > > that if we were to implement our build system on top of these > > reusable scripts, we no doubt would be stretching the > > customization hooks to their limit, but we will want to significantly > > limit what individual module developers can customize. > > > > A couple of particulars that come to mind with our > > compile-default target: > > > > The sourcepath, classpath, and output directory for > > each module are dictated by the build system, not the > > module (so we would want to configure that, but not > > let module developers reconfigure it). > > > > Before the actual compile, we convert the property files > > containing translateable resources to Java files and maintain > > a list of all files needing translation (the translation team, > > which services the entire company, uses that list to drive > > their translations). > > > > In the postulated reusable script scenario, our standard resource > > preprocessing would presumably be plugged in to the > > public distribution as a before target. We want to allow > > modules to provide their own before targets, but not allow > > them to mess with our standard one. > > > > (Actually, while I'm at it, we reflexively provided before and > > after targets for the test phase, which seems to have been a > > mistake. The chief use has been to set up test > > fixtures (starting and stopping web servers, etc), which > > would have been more robust and reusable if done from > > within the JUnit test classes.) > > > > Louis > > > > > --DD > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > I'm not favorable to have such restricting feature embbed in the language. > These kind of things have their place in generic strict imperative > language, > not in a scripting language, not in declarative language, and usually not > in > domain specific language. Could you argue a little bit more? I don't see why we couldn't provide an extension limiting feature to people building build systems from Ant. In large development teams, build team sometimes suffer from developers hacking the build system instead of talking with the build team to get what they want, which can end up in maintenance headaches. Being able to clearly define what can be customized/extended in a build system would be a very good feature for such build teams. I don't know if we would use this kind of feature in EasyAnt, because as I see it it needs to be extremelly flexible. But giving this feature for people who use Ant directly or just want to extend EasyAnt by restriction would be a good thing for such large environment IMHO. Xavier > And IMHO, Ant is a declarative, domain specific > scripting language. > > To put in place such restriction in Ant, you should rather have coding > standards, gui
Re: AW: ant java versions
On Jan 16, 2008 10:28 AM, Steve Loughran <[EMAIL PROTECTED]> wrote: > Peter Reilly wrote: > > > I do not think we should do this. > > As far as I know, there is no super compelling reason to make ant only > > work on java 1.4 +, > > > I was curious as it is a lot easier to do relative URLs with the > java.net.URI class, which is java 1.4+ only > > > java5, on the other hand > > we switched to java5 @ Work, primarily because once you read all the > (wonderful) papers on the Java Memory Model, you can't trust the JVM's > memory accesses to volatile keyworded data in a multithreaded app. > > It does offer lots of advantages > -new collections > -iterators > -ability to have subclasses return subtypes on overridden methods > -concurrency API > > That's before you worry about annotations. > > I think if we made a jump to java5 for Ant1.8 we'd upset all the java1.4 > users out there (and there are still a lot -I can see that for > discussons on testng-users mailing list, people who annotations in > javadoc. However, I can also see that we'd want to move to java 5 > eventually, and we need to move from java1.3 to 1.4 first. So having a > move from java1.3 for java 1.8 would seem a first a step. There are a woe-full amount of java 1.3 users as well.. Peter > > > > -- > Steve Loughran http://www.1060.org/blogxter/publish/5 > Author: Ant in Action http://antbook.org/ > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: ant java versions
Peter Reilly wrote: I do not think we should do this. As far as I know, there is no super compelling reason to make ant only work on java 1.4 +, I was curious as it is a lot easier to do relative URLs with the java.net.URI class, which is java 1.4+ only java5, on the other hand we switched to java5 @ Work, primarily because once you read all the (wonderful) papers on the Java Memory Model, you can't trust the JVM's memory accesses to volatile keyworded data in a multithreaded app. It does offer lots of advantages -new collections -iterators -ability to have subclasses return subtypes on overridden methods -concurrency API That's before you worry about annotations. I think if we made a jump to java5 for Ant1.8 we'd upset all the java1.4 users out there (and there are still a lot -I can see that for discussons on testng-users mailing list, people who annotations in javadoc. However, I can also see that we'd want to move to java 5 eventually, and we need to move from java1.3 to 1.4 first. So having a move from java1.3 for java 1.8 would seem a first a step. -- Steve Loughran http://www.1060.org/blogxter/publish/5 Author: Ant in Action http://antbook.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
I was just saying that Ant benefits/(or suffer...) from great flexibility, and you should not change that. Things like the declarative nature of the targets and global properties participate to this flexibility. The fact that you can overwrite target is also a good support for flexibility. I'm not in favour of adding new features to the language just to allow reducing the flexibility. You can add that on top of the language if you want, but it should not be embedded in the language itself. Ant is language with a simple declarative syntax and a rich set of domain specific 'commands'. The evolution of ant should be first the enrichment of the domain specific commands, then only enhance the declarative syntax. But IMHO it is better to limit those changes to things that could not be done outside the language in order to keep that part of ant as simple as it could. Moreover, there is a big issue with 'final' like keyword. It implies that you must be able to anticipate all the possible extensions of your code when you write it. It is already difficult to do in OO languages that have extension via inheritance as a root paradigm. I think it is not possible with a language like ant. Gilles > -Original Message- > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > Sent: mercredi 16 janvier 2008 9:53 > To: Ant Developers List > Subject: Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java > projects > > On Jan 16, 2008 8:54 AM, Gilles Scokart <[EMAIL PROTECTED]> wrote: > > > 2008/1/15, Louis Tribble <[EMAIL PROTECTED]>: > > > > > > Dominique Devienne wrote: > > > > On 1/15/08, Louis Tribble <[EMAIL PROTECTED]> wrote: > > > > > > > >> Consequently, my main comment (apologies if I missed it in the > > thread) > > > >> is that any magic target overriding feature needs to balanced by > > > >> a target locking feature, for at least two reasons: (1) the integrity > > > of > > > >> the > > > >> build depends on certain chunks of script (typically in the > > xxx-default > > > >> targets) always being invoked and (2) nobody can understand and > > > >> manage a build of 500 modules if modules do their own thing even for > > > >> basic tasks like compiling and creating jars. > > > >> > > > > > > > > This is interesting. So you want some kind of "final" keyword for a > > > > target, to allow controlled customization only, right? Basically the > > > > template method pattern, with an immutable public target, and only > > > > limited customization. > > > > > > > Right. In fact, we were very conscious of applying design > > > patterns to the build system. > > > > > > > >> A corollary is that if I were to base this system on the hypothesized > > > >> Ant-supplied system, I expect I would need to customize quite a bit, > > > >> but I would not want to expose most of that customizability to the > > > >> modules. (Perhaps that is something like what Gilles was thinking > > > >> when he mentioned two levels of customization?) > > > >> > > > > > > > > That's where I'm confused. You want to be able to customize in some > > > > places, but not in others??? I don't quite follow what you mean here. > > > > > > > Sorry if I wasn't clear. Xavier was suggesting (in part) a set > > > of reusable build scripts. To be useful, those scripts need to > > > be customizable in a variety of ways, which led to the > > > discussion of super and before/after and so on. I was noting > > > that if we were to implement our build system on top of these > > > reusable scripts, we no doubt would be stretching the > > > customization hooks to their limit, but we will want to significantly > > > limit what individual module developers can customize. > > > > > > A couple of particulars that come to mind with our > > > compile-default target: > > > > > > The sourcepath, classpath, and output directory for > > > each module are dictated by the build system, not the > > > module (so we would want to configure that, but not > > > let module developers reconfigure it). > > > > > > Before the actual compile, we convert the property files > > > containing translateable resources to Java files and maintain > > > a list of all files needing translation (the translation team, > > > which services the entire company, uses that list to drive > > > their translations). > > > > > > In the postulated reusable script scenario, our standard resource > > > preprocessing would presumably be plugged in to the > > > public distribution as a before target. We want to allow > > > modules to provide their own before targets, but not allow > > > them to mess with our standard one. > > > > > > (Actually, while I'm at it, we reflexively provided before and > > > after targets for the test phase, which seems to have been a > > > mistake. The chief use has been to set up test > > > fixtures (starting and stopping web servers, etc), which > > > would have been more robust and reusable if done from > > > within the JUnit test classes.) > > > >
ClasspathUtils with or vs. JavaResource
Hey, I've been working on refactoring some code to make it easier to implement relative resources in things like the import task. After looking at BaseDef and AntLibDefinition, it seemed that it was a bit backwards and AntlibDefinition should actually extend a base class that provides basic classpath lookups. In trying to do this refactoring, I realized that all of this stuff was just using ClasspathUtils and not using JavaResource or ClasspathResource so I figured the refactoring should include this update as well. However, after digging in, it seems to get very complex... ClasspathUtils (and it's Delegate) does a lot of work to figure out the classloader and reuse one if it can. To do this, there's a bunch of delegate calls that get made and eventually the calling task takes the class loader returned by the delegate and loads the resource (unless it's a file, then it just loads it). With a ClasspathResource, you basically give it the path and the resource name, and it does it's own simpler checks to figure out and reuse the classloader and you can tell it to load the resource. However, you cannot get a reference to the classloader used. My question is, should these be used together? It seems a little overkill to do all the steps required in ClasspathUtils just to get the path for the resource to then in turn pass it to a ClasspathResource which is going to use it's own classloader anyway. There's got to be a cleaner way to do this, i'm just not sure if ClasspathUtils should be updated to return/use ClasspathResources, or if the ClasspathResource should get a little smarter to bypass the utils class alltogether. any thoughts? - Jonathan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
On 1/16/08, Gilles Scokart <[EMAIL PROTECTED]> wrote: > I was just saying that Ant benefits/(or suffer...) from great flexibility, > and you should not change that. [...] I agree with Xavier, control in large build system is a very desirable feature, if only to force developers to talk to the build team to ease restrictions at times, for example. Final methods and classes in Java are not used often, but they are essential for some patterns, and no one forces you to use them. So no, dismissing a feature useful to some, when you are not forced to use it, is not a position I find OSS friendly. For example, I wasn't at first particularly favorable to genericantfile in , which I consider a bit my "baby", yet it was quite useful to some, and they provided patches, so who am I to dismiss their use case? So hint hint Louis, patches for your proposed extension-restricting features useful in large corporate build setting are more than welcome ;-))) --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Need build help
Thanks, if I run: build.sh - everything is fine. build.sh test - run after the first build, I still get the FileNotFound error. For some reason FailedTests.java is never being created. I guess I could comment out the collector for now, but that seems a little weird. - Jonathan On Wed, 2008-01-16 at 07:40 +0100, [EMAIL PROTECTED] wrote: > /optional/out/FailedTests.java is created when running test testsuite. > That file is created by the FailureRecorder: > > build.xml > 1588: > 1610: 1632: > 1635: > 1741: > 1744: > > That Recorder should catch all failing testcases (failing *.test*() > methods), and create > a new JUnit TestSuite which delegates to these failed tests. In a 2nd run, > only these failed > tests should run. > That's the intention ... > > > Jan > > > > -Ursprüngliche Nachricht- > > Von: Peter Reilly [mailto:[EMAIL PROTECTED] > > Gesendet: Dienstag, 15. Januar 2008 21:28 > > An: Ant Developers List; [EMAIL PROTECTED] > > Betreff: Re: Need build help > > > > Yes, this happens sometimes (need to look > > into it!). > > > > I would to ./build.sh, and then ./build.sh test > > > > Peter > > > > On Jan 15, 2008 7:10 PM, jonathan doklovic <[EMAIL PROTECTED]> wrote: > > > I'm building using build.sh now, however if I do: > > > build.sh test > > > > > > the build fails with the following: > > > > > > check-failed: > > > java.io.FileNotFoundException: > > /ant-core/src/etc/testcases/taskdefs/optional/out/FailedTests. > > java (No such file or directory) > > > at java.io.FileOutputStream.open(Native Method) > > > at > > java.io.FileOutputStream.(FileOutputStream.java:179) > > > at > > java.io.FileOutputStream.(FileOutputStream.java:131) > > > at > > > > > org.apache.tools.ant.taskdefs.optional.junit.FailureRecorder.w > > riteJavaClass(FailureRecorder.java:248) > > > at > > > > > org.apache.tools.ant.taskdefs.optional.junit.FailureRecorder.t > > askFinished(FailureRecorder.java:410) > > > at > > > org.apache.tools.ant.Project.fireTaskFinished(Project.java:2117) > > > at org.apache.tools.ant.Task.perform(Task.java:364) > > > at org.apache.tools.ant.Target.execute(Target.java:354) > > > at org.apache.tools.ant.Target.performTasks(Target.java:379) > > > at > > > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1324) > > > at > > org.apache.tools.ant.Project.executeTarget(Project.java:1293) > > > at > > > > > org.apache.tools.ant.helper.DefaultExecutor.executeTargets(Def > > aultExecutor.java:41) > > > at > > > org.apache.tools.ant.Project.executeTargets(Project.java:1176) > > > at org.apache.tools.ant.Main.runBuild(Main.java:758) > > > at org.apache.tools.ant.Main.startAnt(Main.java:217) > > > at > > org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) > > > at > > org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) > > > > > > test: > > > java.io.FileNotFoundException: > > /ant-core/src/etc/testcases/taskdefs/optional/out/FailedTests. > > java (No such file or directory) > > > at java.io.FileOutputStream.open(Native Method) > > > at > > java.io.FileOutputStream.(FileOutputStream.java:179) > > > at > > java.io.FileOutputStream.(FileOutputStream.java:131) > > > at > > > > > org.apache.tools.ant.taskdefs.optional.junit.FailureRecorder.w > > riteJavaClass(FailureRecorder.java:248) > > > at > > > > > org.apache.tools.ant.taskdefs.optional.junit.FailureRecorder.t > > askFinished(FailureRecorder.java:410) > > > at > > > org.apache.tools.ant.Project.fireTaskFinished(Project.java:2117) > > > at org.apache.tools.ant.Task.perform(Task.java:364) > > > at org.apache.tools.ant.Target.execute(Target.java:354) > > > at org.apache.tools.ant.Target.performTasks(Target.java:379) > > > at > > > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1324) > > > at > > org.apache.tools.ant.Project.executeTarget(Project.java:1293) > > > at > > > > > org.apache.tools.ant.helper.DefaultExecutor.executeTargets(Def > > aultExecutor.java:41) > > > at > > > org.apache.tools.ant.Project.executeTargets(Project.java:1176) > > > at org.apache.tools.ant.Main.runBuild(Main.java:758) > > > at org.apache.tools.ant.Main.startAnt(Main.java:217) > > > at > > org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) > > > at > > org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) > > > > > > > > > > > > > > > On Tue, 2008-01-15 at 17:38 +, Peter Reilly wrote: > > > > On Jan 15, 2008 5:19 PM, jonathan doklovic > > <[EMAIL PROTECTED]> wrote: > > > > > oops, sorry i missed that. > > > > > > > > > > Thanks, > > > > No problem, > > > > slightly better build instructions are in the manual: > > > > http://ant.apache.org/manual/install.html
ResolveReport API
Hi, I have a question about the Ivy API. In IvyDE, to compute the classpath there is: ResolveReport r = _ivy.resolve(ivyURL, new ResolveOptions().setConfs(_confs)); all.addAll(Arrays.asList(r.getAllArtifactsReports())); But it seems that the download reports contains also the evicted modules : so the classpath may contains different versions of same library. Is that expected, so there is an IvyDE bug, or it is an Ivy one ? cheers, Nicolas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResolveReport API
On Jan 16, 2008 4:07 PM, Nicolas Lalevée <[EMAIL PROTECTED]> wrote: > Hi, > > I have a question about the Ivy API. In IvyDE, to compute the classpath > there > is: > > ResolveReport r = _ivy.resolve(ivyURL, new > ResolveOptions().setConfs(_confs)); > all.addAll(Arrays.asList(r.getAllArtifactsReports())); > > But it seems that the download reports contains also the evicted modules : > so > the classpath may contains different versions of same library. > Is that expected, so there is an IvyDE bug, or it is an Ivy one ? I'd say Ivy's bug is the lack of documentation of ResolveReport (among many others). It's IvyDE bug to use this method while it doesn't filter out evicted nodes. I guess we should add a method on the report to easily get all non evicted artifacts reports, and use it in IvyDE. Xavier > > > cheers, > Nicolas > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
Re: ClasspathUtils with or vs. JavaResource
jonathan doklovic wrote: Hey, I've been working on refactoring some code to make it easier to implement relative resources in things like the import task. After looking at BaseDef and AntLibDefinition, it seemed that it was a bit backwards and AntlibDefinition should actually extend a base class that provides basic classpath lookups. In trying to do this refactoring, I realized that all of this stuff was just using ClasspathUtils and not using JavaResource or ClasspathResource so I figured the refactoring should include this update as well. However, after digging in, it seems to get very complex... ClasspathUtils (and it's Delegate) does a lot of work to figure out the classloader and reuse one if it can. To do this, there's a bunch of delegate calls that get made and eventually the calling task takes the class loader returned by the delegate and loads the resource (unless it's a file, then it just loads it). With a ClasspathResource, you basically give it the path and the resource name, and it does it's own simpler checks to figure out and reuse the classloader and you can tell it to load the resource. However, you cannot get a reference to the classloader used. My question is, should these be used together? It seems a little overkill to do all the steps required in ClasspathUtils just to get the path for the resource to then in turn pass it to a ClasspathResource which is going to use it's own classloader anyway. There's got to be a cleaner way to do this, i'm just not sure if ClasspathUtils should be updated to return/use ClasspathResources, or if the ClasspathResource should get a little smarter to bypass the utils class alltogether. any thoughts? - Jonathan the two goals of ant's classpath work are (a) reuse stuff so that you can share data properly (b) not leak like a leaky-sieve, and so cause IDEs or app servers to run out of memory The classpath stuff does achieve both, but I'd have to look at all of this to see what is going on. You are clearly provoking us into a code review -- Steve Loughran http://www.1060.org/blogxter/publish/5 Author: Ant in Action http://antbook.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ClasspathUtils with or vs. JavaResource
Well, For now, since the relative path stuff should be going into ResourceFactory, I'll create a new base class that simply checks for name, classname, resource, classpath, and loadrref args and returns a JavaResource using the ResourceFactory. I'll use this as the base for the new import task to allow loading resources (and relative resources) from the classpath and leave the other stuff (DefBase, etc.) as is. Once this is done, it will hopefully be clear to see where to put the http stuff as well. I should be able to get this working pretty quickly, so it can be reviewed and decisions can be made about the use of ClasspathUtils or refactoring the other code. sound like a plan? - Jonathan On Wed, 2008-01-16 at 16:03 +, Steve Loughran wrote: > jonathan doklovic wrote: > > Hey, > > > > I've been working on refactoring some code to make it easier to > > implement relative resources in things like the import task. > > > > After looking at BaseDef and AntLibDefinition, it seemed that it was a > > bit backwards and AntlibDefinition should actually extend a base class > > that provides basic classpath lookups. > > > > In trying to do this refactoring, I realized that all of this stuff was > > just using ClasspathUtils and not using JavaResource or > > ClasspathResource so I figured the refactoring should include this > > update as well. > > > > However, after digging in, it seems to get very complex... > > ClasspathUtils (and it's Delegate) does a lot of work to figure out the > > classloader and reuse one if it can. To do this, there's a bunch of > > delegate calls that get made and eventually the calling task takes the > > class loader returned by the delegate and loads the resource (unless > > it's a file, then it just loads it). > > > > With a ClasspathResource, you basically give it the path and the > > resource name, and it does it's own simpler checks to figure out and > > reuse the classloader and you can tell it to load the resource. However, > > you cannot get a reference to the classloader used. > > > > My question is, should these be used together? It seems a little > > overkill to do all the steps required in ClasspathUtils just to get the > > path for the resource to then in turn pass it to a ClasspathResource > > which is going to use it's own classloader anyway. > > > > There's got to be a cleaner way to do this, i'm just not sure if > > ClasspathUtils should be updated to return/use ClasspathResources, or if > > the ClasspathResource should get a little smarter to bypass the utils > > class alltogether. > > > > any thoughts? > > > > - Jonathan > > > > the two goals of ant's classpath work are > > (a) reuse stuff so that you can share data properly > (b) not leak like a leaky-sieve, and so cause IDEs or app servers to run > out of memory > > The classpath stuff does achieve both, but I'd have to look at all of > this to see what is going on. You are clearly provoking us into a code > review > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
moving to Jira
I know its been discussed before, but I'd to raise the idea again: moving to JIRA for reporting putting aside the main feature for end users -a better UI- what I like about using at work is - automatic polling of SVN and building of a change log from keywords like SFOS-123 http://jira.smartfrog.org/jira/browse/SFOS-570?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel -automatic release note building http://jira.smartfrog.org/jira/secure/ReleaseNote.jspa?projectId=1&styleName=Html&version=10092 the tool encourages you to move to a world of 'declare the bug', commit with the bug ID, close the bug. This is something we sort of do in Ant, but not rigorously enough. Having just started doing some Ant work this week, I can really feel the difference that switching to bugzilla gives, its like moving backwards -steve -- Steve Loughran http://www.1060.org/blogxter/publish/5 Author: Ant in Action http://antbook.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: moving to Jira
On 1/16/08, Steve Loughran <[EMAIL PROTECTED]> wrote: > I know its been discussed before, but I'd to raise the idea again: > moving to JIRA for reporting I know it's GMail's fault, but with bugzilla threading in GMail works most of the time, whereas it's quite broken with JIRA, and that's a PITA IMHO. I wouldn't nix JIRA if enough people want it, but I wouldn't push for it myself obviously... --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: moving to Jira
On Jan 16, 2008 5:25 PM, Steve Loughran <[EMAIL PROTECTED]> wrote: > > I know its been discussed before, but I'd to raise the idea again: > moving to JIRA for reporting > > putting aside the main feature for end users -a better UI- what I like > about using at work is > > - automatic polling of SVN and building of a change log from keywords > like SFOS-123 > > http://jira.smartfrog.org/jira/browse/SFOS-570?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel > > -automatic release note building > > http://jira.smartfrog.org/jira/secure/ReleaseNote.jspa?projectId=1&styleName=Html&version=10092 > > the tool encourages you to move to a world of 'declare the bug', commit > with the bug ID, close the bug. This is something we sort of do in Ant, > but not rigorously enough. Having just started doing some Ant work this > week, I can really feel the difference that switching to bugzilla gives, > its like moving backwards +1 And for Ivy we use JIRA, so it would also be more uniform to use the same tools. Xavier > > -steve > > > > -- > Steve Loughran http://www.1060.org/blogxter/publish/5 > Author: Ant in Action http://antbook.org/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
Re: moving to Jira
I use gmail, and find the JIRA conversation per message a mess. I would be -1 until this has been resolved. Peter On Jan 16, 2008 4:47 PM, Xavier Hanin <[EMAIL PROTECTED]> wrote: > On Jan 16, 2008 5:25 PM, Steve Loughran <[EMAIL PROTECTED]> wrote: > > > > > I know its been discussed before, but I'd to raise the idea again: > > moving to JIRA for reporting > > > > putting aside the main feature for end users -a better UI- what I like > > about using at work is > > > > - automatic polling of SVN and building of a change log from keywords > > like SFOS-123 > > > > http://jira.smartfrog.org/jira/browse/SFOS-570?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel > > > > -automatic release note building > > > > http://jira.smartfrog.org/jira/secure/ReleaseNote.jspa?projectId=1&styleName=Html&version=10092 > > > > the tool encourages you to move to a world of 'declare the bug', commit > > with the bug ID, close the bug. This is something we sort of do in Ant, > > but not rigorously enough. Having just started doing some Ant work this > > week, I can really feel the difference that switching to bugzilla gives, > > its like moving backwards > > +1 > > And for Ivy we use JIRA, so it would also be more uniform to use the same > tools. > > Xavier > > > > > > > -steve > > > > > > > > -- > > Steve Loughran http://www.1060.org/blogxter/publish/5 > > Author: Ant in Action http://antbook.org/ > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Xavier Hanin - Independent Java Consultant > http://xhab.blogspot.com/ > http://ant.apache.org/ivy/ > http://www.xoocode.org/ > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Dominique Devienne wrote: On 1/16/08, Gilles Scokart <[EMAIL PROTECTED]> wrote: I was just saying that Ant benefits/(or suffer...) from great flexibility, and you should not change that. [...] I agree with Xavier, control in large build system is a very desirable feature, if only to force developers to talk to the build team to ease restrictions at times, for example. Very much. We know we haven't anticipated everything, but our old build system--with few restrictions and little prescribed structure, and everybody piling on--was on the point of collapse, even though the system was a lot smaller then. Individual module developers may not even be aware of the design goals and invariants of the build system, and even if aware, don't necessarily have any incentive to go out of their way to preserve them. (The engineers involved in the new build system were and are just developers with other responsibilities who got fed up with the old system, spending time policing checkins for signs of rot was never an option.) Final methods and classes in Java are not used often, but they are essential for some patterns, and no one forces you to use them. So no, dismissing a feature useful to some, when you are not forced to use it, is not a position I find OSS friendly. For example, I wasn't at first particularly favorable to genericantfile in , which I consider a bit my "baby", yet it was quite useful to some, and they provided patches, so who am I to dismiss their use case? What prompted me to speak up is that right now, the way imports and overriding work, we at least have some control, and I was concerned to lose even that. The module-specific overriding targets are imported after the mandatory targets are defined but before the empty default before and after targets are defined, so a module can override the before and after targets but not the mandatory targets. My concern is that a generic override feature will undermine the restriction. So hint hint Louis, patches for your proposed extension-restricting features useful in large corporate build setting are more than welcome ;-))) I'm not optimistic, but I'll try... Right now, if I contribute anywhere, it should be to the JUnit tasks, probably. I've been bumping up against them a lot. Louis --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: moving to Jira
I was +1 on this before, and I am +1 now, particularly since Ivy uses it. But the objection that others have concerning threading when reading with GMail is a fair reason for vetoing again, as happened before. I've filed a bug report with Google on their lack of support for observing the In-Reply-To header at https://mail.google.com/support/bin/request.py?direct=1. I suggest you all do the same. Perhaps we can encourage them to move toward being more compliant with RFC-2822. Then we can finally get the Ant project onto Jira. Steve Loughran wrote: I know its been discussed before, but I'd to raise the idea again: moving to JIRA for reporting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: moving to Jira
Yes, I filed it too some time ago. I do not see them fixing it. - Alexey. On Jan 16, 2008 11:42 AM, Bruce Atherton <[EMAIL PROTECTED]> wrote: > I was +1 on this before, and I am +1 now, particularly since Ivy uses > it. But the objection that others have concerning threading when reading > with GMail is a fair reason for vetoing again, as happened before. > > I've filed a bug report with Google on their lack of support for > observing the In-Reply-To header at > https://mail.google.com/support/bin/request.py?direct=1. I suggest you > all do the same. Perhaps we can encourage them to move toward being > more compliant with RFC-2822. Then we can finally get the Ant project > onto Jira. > > Steve Loughran wrote: > > > > I know its been discussed before, but I'd to raise the idea again: > > moving to JIRA for reporting > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Alexey N. Solofnenko Home: http://trelony.cjb.net/ Pleasant Hill, CA (GMT-8 usually)
Re: AW: ant java versions
Peter Reilly wrote: There are a woe-full amount of java 1.3 users as well.. Peter And of 1.2 users that we abandoned during the 1.7 release. But the thinking at that time, and I think it holds up here as well, is that if those users are too conservative to move beyond a JVM which has now reached end-of-life, they are also too conservative to upgrade to the latest version of Ant. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[JUST NOISE] forwarding test for ivy-dev
Just a test - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: ant java versions
On Jan 17, 2008 12:19 AM, Bruce Atherton <[EMAIL PROTECTED]> wrote: > Peter Reilly wrote: > > There are a woe-full amount of java 1.3 users as well.. > > > > Peter > > > > > > And of 1.2 users that we abandoned during the 1.7 release. But the > thinking at that time, and I think it holds up here as well, is that if > those users are too conservative to move beyond a JVM which has now > reached end-of-life, they are also too conservative to upgrade to the > latest version of Ant. > The main reason (IMO) we moved from java 1.2, was that it java5's javac generated bad byte code for java 1.2. Peter > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: moving to Jira
+1, I found jira much more confortable, and I would like to see ant using the same bug tracking system than ivy. Gilles 2008/1/16, Steve Loughran <[EMAIL PROTECTED]>: > > > I know its been discussed before, but I'd to raise the idea again: > moving to JIRA for reporting > > putting aside the main feature for end users -a better UI- what I like > about using at work is > > - automatic polling of SVN and building of a change log from keywords > like SFOS-123 > > http://jira.smartfrog.org/jira/browse/SFOS-570?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel > > -automatic release note building > > http://jira.smartfrog.org/jira/secure/ReleaseNote.jspa?projectId=1&styleName=Html&version=10092 > > the tool encourages you to move to a world of 'declare the bug', commit > with the bug ID, close the bug. This is something we sort of do in Ant, > but not rigorously enough. Having just started doing some Ant work this > week, I can really feel the difference that switching to bugzilla gives, > its like moving backwards > > -steve > > > > -- > Steve Loughran http://www.1060.org/blogxter/publish/5 > Author: Ant in Action http://antbook.org/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Gilles Scokart
