Alexey Solofnenko wrote: > I have written an ANT pre-processor that supports "smart" includes with > support of rebasing properties and paths, and renaming properties and > targets to avoid clashes. It supports recursive includes, so build files > can reference each others properties and targets. It is also possible to > generate some includes with a script and overwrite targets in other build > files. I will ask my boss for permission to publish the code.
I think it would be more usefull to contribute informations about your use cases. We (hopefully) agreed on adding <import>, now the question is "What's the cleanest and simplest default behavior". We can tune it with attributes, but if a user just types: <import file="foo/bar.xml" /> we need to know how to resolve the relative paths. What's the behavior in your preprocessor ? Costin > > - Alexey. > > -----Original Message----- > From: Costin Manolache [mailto:[EMAIL PROTECTED] > Sent: Friday, January 10, 2003 7:08 AM > To: [EMAIL PROTECTED] > Subject: RE: Improt task and project basedir > > Jose Alberto Fernandez wrote: > >> Do you really think I can get the buildfiles of lets say 5 different >> jakarta projects and just import all of them on my build file and then >> with a few additional main targets being able to build all those projects >> on one go? > > Why not ? > > Maybe not any 5 different projects - but at least for the 4-5 tomcat > components, most commons, etc. Maybe with small changes. > > >> What about clashes on property names? Are we going to have separte names >> spaces for properties declared in different import files? How would I >> access properties fro imported build files then. > > Property names - clashes are desirable :-) ( i.e. same naming conventions > for locating .jars, paths, etc ). > > For targets - we already rewrite then on conflict. That's where some > changes may be needed in the build files. > > I'm not sure I understood your proposal for basedir - you disagree with > using the imported file basedir as default, but I fail to see what > alternative you propose and what use case. > > > Costin > > > > -- > 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]>
