If I was looking for something easier to read, XML probably wouldn't be it for me, as
for (int i=1; i <= 6; i++) someProcess(i); makes that example a lot more readable. Neither antcall or template work for me in that case. On the complex expressions, we already have that in Maven today and have had for quite a while, using Jelly as the property context for ant, so having it as a planned addition doesn't help me much. And we can already do exactly what you're describing by binding project.xml as a property, and use jexl to access methods or properties as needed. The two current drivers for Maven under development do exactly what you're describing - load properties once and coordinate the calling. You're right, it is much faster. What you describe looks like it would work for us, but I feel by the time you get to it, we'll have moved on. We addressed a lot of these issues in prototypes over the last few weeks. We even have an option where there's a replacement Ant syntax using Jelly and Werkz. I'd love for there to be more synergy between the groups, but as one of the few cross-over people, it's hard, as Ant has been stuck in v1 mode for a long, long time, and Maven needs things easier, and I think in a timeframe that Ant couldn't do, due to it's large user base. There are lots of simple ant issues that should have been worked out long ago (XML classes and JDK 1.4 clashing with ant for example), but linger on. I'm not sure why this is the case. -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers Peter Donald <[EMAIL PROTECTED]> 06/23/02 05:20 PM Please respond to "Ant Developers List" To "Ant Developers List" <[EMAIL PROTECTED]> cc bcc Subject Re: Object oriented builds At 04:36 PM 6/23/2002 +1000, you wrote: >Templates aren't the major hassle with build file reuse. I dunno - which of the following do you think is easiedr to read <do-some-process param="1"/> <do-some-process param="2"/> <do-some-process param="3"/> <do-some-process param="4"/> <do-some-process param="5"/> <do-some-process param="6"/> vs <antcall target="some-process"> <param name="param" value="1"/> </antcall> <antcall target="some-process"> <param name="param" value="2"/> </antcall> <antcall target="some-process"> <param name="param" value="3"/> </antcall> <antcall target="some-process"> <param name="param" value="4"/> </antcall> <antcall target="some-process"> <param name="param" value="5"/> </antcall> <antcall target="some-process"> <param name="param" value="6"/> </antcall> The second version is likely to be much much more slower and requires you to at least be aware of different scoping rules in ant. > The main one is >property sharing and passing. Ant2 unifies the namespace of data values and properties. Hence complex values can be stored as normal properties. A planned addition, that is not yet done in myrmidon, is to allow a complex expression language to be used in projects that demand it (ie Maven/centipede). So you could load an xml snippet (like project.xml) bind it to a property (say myproject) and then reference values inside that complex object. ie Using an xpath style syntax you could refer to property like "${myproject:/project/maven/version}" or whatever. So in theory that way a maven build would load project.xml once and never use <ant/> <antcall/>. This should produce a much faster build and hopefully be easier to maintain for you. As soon as I bring the memory usage down to sane levels I actually plan to get you maven guys to see if it works for all the things you need to do. If not we can try to figure something further out. Does the above look like it would work for you or not? Cheers, Peter Donald ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Faced with the choice between changing one's mind, and proving that there is no need to do so - almost everyone gets busy on the proof." - John Kenneth Galbraith ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
