Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
An other thing to specify with before is its position relatively to the dependencies of the 'extended' taget. Do we place the before really just before the target itself, or before the dependencies of the target? The second aproach is currently possible from the script that want to extend an imported script: target name=pre-foo /target target name=foo depends=pre-foo , imported.foo/ The first aproach requires that the imported script has anticipated te need : target name=just-before-foo/ target name=foo depends=foo-depends,just-before-foo/ -- Gilles Scokart
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
On Jan 15, 2008 9:00 AM, Gilles Scokart [EMAIL PROTECTED] wrote: An other thing to specify with before is its position relatively to the dependencies of the 'extended' taget. Do we place the before really just before the target itself, or before the dependencies of the target? IMO it should be just before the target itself. Being before the target dependencies will probably end up being at the beginning of the build in many cases. Xavier -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
2008/1/14, Dominique Devienne [EMAIL PROTECTED]: On 1/14/08, Stefan Bodewig [EMAIL PROTECTED] wrote: Dominique Devienne [EMAIL PROTECTED] writes: Having something like before/after/around advices (where around is the same as an override that doesn't change the dependencies list) may suffice and leave overwriting the whole target definition to the worst case. Thanks for reminding me of this issue Stefan. Indeed, something I really didn't like about overriding the whole target, is that you had to duplicate the dependency list as well... Which is why I now remember that I now remember I used 4, not 3 targets, in the abstract build, the forth one being the target's own content, separate from its dependency list: So every concrete simple target like target name=foo depends=bar, baz / became target name=foo depends=bar, baz, -pre-foo, -foo, -post-foo / target name=-foo ... /target target name=-pre-foo / target name=-post-foo / in the abstract build. Override -foo to replace just the target content, without it's dependency list. Or override foo to have complete control, but in my experience it's -foo that needed overriding, not foo. Note though that unlike before and after, around isn't as representative a name. When I thought about this issue a while back, I thought of using a magic name such as super in the depends attribute to refer to the overridden target's dependency list, similar to using super/ in the target's body to refer to the overridden target's task list/content. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Using the imported_script_name.target syntax give you already some flexibility. -- Gilles Scokart
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
On Jan 15, 2008 6:31 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: Peter Reilly [EMAIL PROTECTED] writes: I would say that if the build file does not specify the order, then the order is undefined. If the order is important, then the build file can enforce an order by using depends. target name=prepare before=junit depends=start-server prepare / /target One thing we are not taking into account is the plugin approach that is part of Xavier's initial EasyAnt vision. If our base build file contains a compile target and several plugins that I want to use need to do stuff before the compile target then we need a way to have a defined order. In the order my build file requires the plugins, I guess. Yes, I agree order should be predictable, and keeping definition order seems fine. Do we revert the order for after targets so the first one declared gets executed last? Why not. But in my mind if you really need to do something surrounding a target, you'd better use the around mechanism than the after / before. I think it's more explicit. The problem with the around mechanism as I see it (which is basically an override with a mean to call the original definition) is the interaction between plugins. If several plugins use the around mechanism, it maybe difficult to understand that the call to the original defintion actually call the definition overriden by another plugin. And if one plugin actually overrides a definition without calling the original definition, then the order will be very important: if it's defined after a plugin overriding just for the around, then I guess the final override will override everything including the overriden definition. So it's very different from what would have happened while using a before and after targets (well, as I see it, see below). Also we will need to define how before/after an complete overriding of targets interact. Do before/after apply to the new definition of the target or are they dropped? I'd say they apply to the new definition. If we take the example of the server start / stop, I think it still makes sense to run 'em when another plugin redefines how the unit tests are run. In my mind plugins interactions should be kept minimal as long as they aren't explicitly desired. If a plugin really wants to disable another plugin 'before' target, then we should provide a mean to do it, like overriding the before target. I'm not sure if there is a use case for that though. As I said before the main problem about plugin interaction is when two plugins override the definition of a target, and at least one doesn't call the original definition. Maybe this shouldn't be considered at the same level: defining before and after targets can be seen as a plugin contribution. Overriding a target is closer to OO inheritance, and as such maybe could be allowed only when a build script 'extends' another one. Hence we would have two kind of relationship between build modules: - a build module 'contributes' to another one, in which case it can only define after/before targets. This is called a plugin. - a build module 'extends' another one, in which case it can override parent target(s) definition(s) Only one 'extension' of a given module can be used at a time in the build system, while the number of contributions is not limited. Does this make sense? Xavier Stefan - 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/
ant java versions
this is a silly question, but I have forgotten the current values 1. What is the minimum version of Ant that 1.7.0 supports? 2. What is the minimum version of Ant that 1.8 is targeting? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41701] - [PATCH] import should be able to load .xmls from classpath
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41701. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41701 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2008-01-15 02:43 --- *** Bug 44214 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
Gilles Scokart [EMAIL PROTECTED] writes: An other thing to specify with before is its position relatively to the dependencies of the 'extended' taget. Do we place the before really just before the target itself, or before the dependencies of the target? Just before the target itself. The second aproach is currently possible from the script that want to extend an imported script: True, but an before attribute would be more readable IMHO. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant java versions
Steve Loughran [EMAIL PROTECTED] writes: this is a silly question, but I have forgotten the current values 1. What is the minimum version of Ant that 1.7.0 supports? In theory the answer is 1.2, but I doubt that anybody really still has an environment to try that. 2. What is the minimum version of Ant that 1.8 is targeting? I'm not sure whether we've made any decision to change what we have as a minimum requirement for 1.7. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41701] - [PATCH] import should be able to load .xmls from classpath
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41701. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41701 [EMAIL PROTECTED] changed: What|Removed |Added BugsThisDependsOn||44239 --- Additional Comments From [EMAIL PROTECTED] 2008-01-15 02:54 --- linking to the changes needed in the resources to start enabling this -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: ant java versions
this is a silly question, but I have forgotten the current values 1. What is the minimum version of Ant that 1.7.0 supports? In theory the answer is 1.2, but I doubt that anybody really still has an environment to try that. 2. What is the minimum version of Ant that 1.8 is targeting? I'm not sure whether we've made any decision to change what we have as a minimum requirement for 1.7. we dropped 1.2, so it is 1.3 http://marc.info/?l=ant-devm=117794737813795w=2 Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: AW: ant java versions
2. What is the minimum version of Ant that 1.8 is targeting? I'm not sure whether we've made any decision to change what we have as a minimum requirement for 1.7. we dropped 1.2, so it is 1.3 http://marc.info/?l=ant-devm=117794737813795w=2 OK. Ant 1.3 is still out there. It would be nice to move up to 1.4 for the 1.8 codebase, at least for some things. I wonder how much use of 1.3 is out there? I think there was already a try to start a vote of dropping Java 1.3 as it should be at end of life. But if I remember right without any success. What is the newest JDK version on our supported platforms? Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: ant java versions
[EMAIL PROTECTED] wrote: this is a silly question, but I have forgotten the current values 1. What is the minimum version of Ant that 1.7.0 supports? In theory the answer is 1.2, but I doubt that anybody really still has an environment to try that. 2. What is the minimum version of Ant that 1.8 is targeting? I'm not sure whether we've made any decision to change what we have as a minimum requirement for 1.7. we dropped 1.2, so it is 1.3 http://marc.info/?l=ant-devm=117794737813795w=2 OK. Ant 1.3 is still out there. It would be nice to move up to 1.4 for the 1.8 codebase, at least for some things. I wonder how much use of 1.3 is out there? -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: ant java versions
[EMAIL PROTECTED] wrote: 2. What is the minimum version of Ant that 1.8 is targeting? I'm not sure whether we've made any decision to change what we have as a minimum requirement for 1.7. we dropped 1.2, so it is 1.3 http://marc.info/?l=ant-devm=117794737813795w=2 OK. Ant 1.3 is still out there. It would be nice to move up to 1.4 for the 1.8 codebase, at least for some things. I wonder how much use of 1.3 is out there? I think there was already a try to start a vote of dropping Java 1.3 as it should be at end of life. But if I remember right without any success. What is the newest JDK version on our supported platforms? Java 6.0u4 on windows/linux, mac still trailing. The 6.04 release changed bits of the XML APIs, which was very unusual for a point release, to say the least. -- 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: svn commit: r612091 - /ant/core/trunk/src/main/org/apache/tools/ant/types/resources/AbstractClasspathResource.java
[EMAIL PROTECTED] wrote: Author: jhm Date: Tue Jan 15 04:06:19 2008 New Revision: 612091 URL: http://svn.apache.org/viewvc?rev=612091view=rev Log: - spelling - a sentence was incomplete (missing additional docs?) Modified: ant/core/trunk/src/main/org/apache/tools/ant/types/resources/AbstractClasspathResource.java Modified: ant/core/trunk/src/main/org/apache/tools/ant/types/resources/AbstractClasspathResource.java URL: http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/types/resources/AbstractClasspathResource.java?rev=612091r1=612090r2=612091view=diff == --- ant/core/trunk/src/main/org/apache/tools/ant/types/resources/AbstractClasspathResource.java (original) +++ ant/core/trunk/src/main/org/apache/tools/ant/types/resources/AbstractClasspathResource.java Tue Jan 15 04:06:19 2008 @@ -26,8 +26,8 @@ I mustnt have saved the copy open in jedit...thanks for catching this - 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/14/08, Stefan Bodewig [EMAIL PROTECTED] wrote: If our base build file contains a compile target and several plugins that I want to use need to do stuff before the compile target then we need a way to have a defined order. In the order my build file requires the plugins, I guess. So far we've been talking mostly about a concrete build needing a customize the behavior of a base generic build, typically with some pre or post processing, and sometimes complete override of the target (w/ or w/o changing the dependency list), but when you mentioned the plugins scenario, it made me think of a composite build made up of several builds you'd import, all with a compile target, where you'd want the compile targets to somehow aggregate into a single compile target... So instead of doing a subant on these builds, you'd import them, and they merge into one build. Sounds a bit crazy, I agree. Oh well, I'm throwing it out there, but it's probably too weird. I'd be quite happy if we simply added before/after support, nailing down the exact desired behavior. Maybe we should indeed do that in another thread. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: ant java versions
On Jan 15, 2008 12:51 PM, [EMAIL PROTECTED] wrote: 2. What is the minimum version of Ant that 1.8 is targeting? I'm not sure whether we've made any decision to change what we have as a minimum requirement for 1.7. we dropped 1.2, so it is 1.3 http://marc.info/?l=ant-devm=117794737813795w=2 OK. Ant 1.3 is still out there. It would be nice to move up to 1.4 for the 1.8 codebase, at least for some things. I wonder how much use of 1.3 is out there? I think there was already a try to start a vote of dropping Java 1.3 as it should be at end of life. 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 +, java5, on the other hand Peter But if I remember right without any success. What is the newest JDK version on our supported platforms? Jan - 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: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
By the way, a truly generic build script will probably have to support 2 level of customization/extension. The first one being an enterprise level, and the second one being at project level. Gilles - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Need build help
Hi, I checked out the core trunk and tried to run the main target in the build file. I get the following error: test-jar: BUILD FAILED ant-core/build.xml:859: We cannot build the test jar unless JUnit is present, as JUnit is needed to compile the test classes. Shouldn't the test-jar target be smart enough to figure out that if junit.present = false then it should use the junit in the optional lib dir? - Jonathan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need build help
You need to follow exactly the build instructions: 1) check out ant to ANT_SOURCE 2) cd to ANT_SOURCE 3) ensure that CLASSPATH env variable is empty 4) place optional jars in ANT_SOURCE/lib/optional 5) ./build.sh - i.e. do not use ant to build ant. Peter On Jan 15, 2008 5:05 PM, jonathan doklovic [EMAIL PROTECTED] wrote: Hi, I checked out the core trunk and tried to run the main target in the build file. I get the following error: test-jar: BUILD FAILED ant-core/build.xml:859: We cannot build the test jar unless JUnit is present, as JUnit is needed to compile the test classes. Shouldn't the test-jar target be smart enough to figure out that if junit.present = false then it should use the junit in the optional lib dir? - Jonathan - 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: Need build help
oops, sorry i missed that. Thanks, - Jonathan On Tue, 2008-01-15 at 17:15 +, Peter Reilly wrote: You need to follow exactly the build instructions: 1) check out ant to ANT_SOURCE 2) cd to ANT_SOURCE 3) ensure that CLASSPATH env variable is empty 4) place optional jars in ANT_SOURCE/lib/optional 5) ./build.sh - i.e. do not use ant to build ant. Peter On Jan 15, 2008 5:05 PM, jonathan doklovic [EMAIL PROTECTED] wrote: Hi, I checked out the core trunk and tried to run the main target in the build file. I get the following error: test-jar: BUILD FAILED ant-core/build.xml:859: We cannot build the test jar unless JUnit is present, as JUnit is needed to compile the test classes. Shouldn't the test-jar target be smart enough to figure out that if junit.present = false then it should use the junit in the optional lib dir? - Jonathan - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need build help
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#buildingant Peter - Jonathan On Tue, 2008-01-15 at 17:15 +, Peter Reilly wrote: You need to follow exactly the build instructions: 1) check out ant to ANT_SOURCE 2) cd to ANT_SOURCE 3) ensure that CLASSPATH env variable is empty 4) place optional jars in ANT_SOURCE/lib/optional 5) ./build.sh - i.e. do not use ant to build ant. Peter On Jan 15, 2008 5:05 PM, jonathan doklovic [EMAIL PROTECTED] wrote: Hi, I checked out the core trunk and tried to run the main target in the build file. I get the following error: test-jar: BUILD FAILED ant-core/build.xml:859: We cannot build the test jar unless JUnit is present, as JUnit is needed to compile the test classes. Shouldn't the test-jar target be smart enough to figure out that if junit.present = false then it should use the junit in the optional lib dir? - Jonathan - 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] - 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
To me, the super-compelling reason is that if we claim to support Java 1.3, then we have to make sure to test against it on all supported platforms. This is a lot of extra work (on top of the testing for 1.4, 1.5, and 1.6), particularly if none of us has Java 1.3 installed. This has bitten us in the past, where JDK 1.2 support in Ant broke without anybody realizing it. Since Java 1.3 is at end of life, what is the benefit to keeping it? It is true that we will see the real benefit in the codebase once we can support only 1.5 and higher, but deprecating support for Java 1.3 is a step to getting us there. Ant 1.8 can target Java 1.4, and then Ant 1.9 (2.0?) can target 1.5. That way the Java versions we support are deprecated gradually. 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 +, java5, on the other hand Peter
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
We have a scheme like some that have been mentioned, in which the system is broken into modules and building the system means looping through the modules applying the same build script to each. The build of each module is broken down into phases, e.g., assemble, compile, create-jar, test, etc (that aspect is fairly Mavenish, I think). Each phase has at least 4 targets: the composite public one, the mandatory default implementation, and the empty, but overridable by each module, before and after hooks, e.g.: target name=compile depends=assemble,compile-before,compile-default,compile-after/ We are pushing 500 modules now, with a hundredish developers, many of them determined (it sometimes seems) to abuse any and all provided customization points. 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. 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?) Regards, Louis Tribble - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need build help
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.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:131) at org.apache.tools.ant.taskdefs.optional.junit.FailureRecorder.writeJavaClass(FailureRecorder.java:248) at org.apache.tools.ant.taskdefs.optional.junit.FailureRecorder.taskFinished(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(DefaultExecutor.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.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:131) at org.apache.tools.ant.taskdefs.optional.junit.FailureRecorder.writeJavaClass(FailureRecorder.java:248) at org.apache.tools.ant.taskdefs.optional.junit.FailureRecorder.taskFinished(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(DefaultExecutor.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#buildingant Peter - Jonathan On Tue, 2008-01-15 at 17:15 +, Peter Reilly wrote: You need to follow exactly the build instructions: 1) check out ant to ANT_SOURCE 2) cd to ANT_SOURCE 3) ensure that CLASSPATH env variable is empty 4) place optional jars in ANT_SOURCE/lib/optional 5) ./build.sh - i.e. do not use ant to build ant. Peter On Jan 15, 2008 5:05 PM, jonathan doklovic [EMAIL PROTECTED] wrote: Hi, I checked out the core trunk and tried to run the main target in the build file. I get the following error: test-jar: BUILD FAILED ant-core/build.xml:859: We cannot build the test jar unless JUnit is present, as JUnit is needed to compile the test classes. Shouldn't the test-jar target be smart enough to figure out that if junit.present = false then it should use the junit in the optional lib dir? - Jonathan - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
On Jan 15, 2008 7:39 PM, Louis Tribble [EMAIL PROTECTED] wrote: We have a scheme like some that have been mentioned, in which the system is broken into modules and building the system means looping through the modules applying the same build script to each. The build of each module is broken down into phases, e.g., assemble, compile, create-jar, test, etc (that aspect is fairly Mavenish, I think). Each phase has at least 4 targets: the composite public one, the mandatory default implementation, and the empty, but overridable by each module, before and after hooks, e.g.: target name=compile depends=assemble,compile-before,compile-default,compile-after/ We are pushing 500 modules now, with a hundredish developers, many of them determined (it sometimes seems) to abuse any and all provided customization points. 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, something like final methods in Java. It makes sense, I like that. Xavier 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. 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?) Regards, Louis Tribble - 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: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
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. 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. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:131) at org.apache.tools.ant.taskdefs.optional.junit.FailureRecorder.writeJavaClass(FailureRecorder.java:248) at org.apache.tools.ant.taskdefs.optional.junit.FailureRecorder.taskFinished(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(DefaultExecutor.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.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:131) at org.apache.tools.ant.taskdefs.optional.junit.FailureRecorder.writeJavaClass(FailureRecorder.java:248) at org.apache.tools.ant.taskdefs.optional.junit.FailureRecorder.taskFinished(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(DefaultExecutor.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#buildingant Peter - Jonathan On Tue, 2008-01-15 at 17:15 +, Peter Reilly wrote: You need to follow exactly the build instructions: 1) check out ant to ANT_SOURCE 2) cd to ANT_SOURCE 3) ensure that CLASSPATH env variable is empty 4) place optional jars in ANT_SOURCE/lib/optional 5) ./build.sh - i.e. do not use ant to build ant. Peter On Jan 15, 2008 5:05 PM, jonathan doklovic [EMAIL PROTECTED] wrote: Hi, I checked out the core trunk and tried to run the main target in the build file. I get the following error: test-jar: BUILD FAILED ant-core/build.xml:859: We cannot build the test jar unless JUnit is present, as JUnit is needed to compile the test classes. Shouldn't the test-jar target be smart enough to figure out that if junit.present = false then it should use the junit in the optional lib dir? - Jonathan - 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] - 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/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]
Re: AW: ant java versions
Hi all, To me, the super-compelling reason is that if we claim to support Java 1.3, then we have to make sure to test against it on all supported platforms. This is a lot of extra work (on top of the testing for 1.4, 1.5, and 1.6), particularly if none of us has Java 1.3 installed. This has bitten us in the past, where JDK 1.2 support in Ant broke without anybody realizing it. Since Java 1.3 is at end of life, what is the benefit to keeping it? I agree with this - I've tried to build our current 1.7.1 branch on 1.3 and it simply won't build right now (I can't remember the exact error I think it was XML api related). Sun don't support java 1.3 (indeed 1.4 will soon be end of life). Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: svn commit: r612091 - /ant/core/trunk/src/main/org/apache/tools/ant/types/resources/AbstractClasspathResource.java
ant/core/trunk/src/main/org/apache/tools/ant/types/resources/AbstractCla sspathResource.java Tue Jan 15 04:06:19 2008 @@ -26,8 +26,8 @@ I mustnt have saved the copy open in jedit...thanks for catching this There was an uncomplete sentence in the doc. Maybe you want to comment more? Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Need build help
/optional/out/FailedTests.java is created when running test testsuite.
That file is created by the FailureRecorder:
build.xml
1588:macrodef name=test-junit
1610:junit printsummary=${junit.summary}
1632: formatter type=failure usefile=false/
1635: test name=${junit.collector.class} if=hasFailingTests/
1741:test-junit
1744: batchtest todir=${build.junit.xml} unless=hasFailingTests
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.init(FileOutputStream.java:179)
at
java.io.FileOutputStream.init(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.init(FileOutputStream.java:179)
at
java.io.FileOutputStream.init(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#buildingant
Peter
- Jonathan
On Tue, 2008-01-15 at 17:15 +, Peter Reilly wrote:
You need to follow exactly the build instructions:
1) check out ant to ANT_SOURCE
2) cd to ANT_SOURCE
3) ensure that CLASSPATH env variable is empty
4) place optional jars in ANT_SOURCE/lib/optional
5) ./build.sh
- i.e. do not use ant to build ant.
Peter
On Jan 15, 2008 5:05 PM, jonathan doklovic
[EMAIL PROTECTED] wrote:
Hi,
I checked out the core trunk
AW: AW: ant java versions
Build on [EMAIL PROTECTED]: java version 1.3.0 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C) Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode) build ... Bootstrapping Ant Distribution ... Building Ant Distribution build: Created dir: C:\ant\svn-repository\ant\core\build\lib Compiling 257 source files to C:\ant\svn-repository\ant\core\build\classes Note: Some input files use or override a deprecated API. jars: skipping a lot of jars as I build without 3rd party libs hint: are there 1.3compliant 3rd party libs? compile-tests: Created dir: C:\ant\svn-repository\ant\core\build\testcases Compiling 265 source files to C:\ant\svn-repository\ant\core\build\testcases Note: Some input files use or override a deprecated API. test-jar: Building jar: C:\ant\svn-repository\ant\core\build\lib\ant-testutil.jar dist-lite: Created dir: C:\ant\svn-repository\ant\core\bootstrap Created dir: C:\ant\svn-repository\ant\core\bootstrap\bin Created dir: C:\ant\svn-repository\ant\core\bootstrap\lib Copying 8 files to C:\ant\svn-repository\ant\core\bootstrap\lib Copying 2 files to C:\ant\svn-repository\ant\core\bootstrap\lib Copying 13 files to C:\ant\svn-repository\ant\core\bootstrap\bin BUILD SUCCESSFUL Total time: 22 seconds ... Cleaning Up Build Directories ... Done Bootstrapping Ant Distribution build: [javac] Compiling 719 source files to C:\ant\svn-repository\ant\core\build\classes [javac] Note: Some input files use or override a deprecated API. jars: ... compile-tests: ... dist-lite: [mkdir] Created dir: C:\ant\svn-repository\ant\core\dist [mkdir] Created dir: C:\ant\svn-repository\ant\core\dist\bin [mkdir] Created dir: C:\ant\svn-repository\ant\core\dist\lib [copy] Copying 8 files to C:\ant\svn-repository\ant\core\dist\lib [copy] Copying 2 files to C:\ant\svn-repository\ant\core\dist\lib [copy] Copying 13 files to C:\ant\svn-repository\ant\core\dist\bin main: BUILD SUCCESSFUL ---8888888--- -8- Strange that there are deprecated warnings even on 1.3 ... But the build works :) Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: ant java versions
Hi, Strange that there are deprecated warnings even on 1.3 ... But the build works :) I'm pretty sure that the tests don't though :( Kev - 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
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. And IMHO, Ant is a declarative, domain specific scripting language. To put in place such restriction in Ant, you should rather have coding standards, guidelines or policies, maybe enforced by a PMD-like validation (I don't know if that exists for ant). -- Gilles Scokart
