Dominique Devienne wrote:
From: Steve Loughran [mailto:[EMAIL PROTECTED] One change I have also checked in to Definer.java is some extra logic for naming antlibs. Instead of justantlib:org.example.package you can go antlib://org/example/package/file.xml and have that file's declarations read in. This will let me keep a set of antlibs in a single dir, load it with -lib and then have antlib://m2-macros.xml antlib://sf-macros.xml So, I am clearly +1 in having this feature. What I am 0 about is the exact syntax. Should it be a full path like what I have done, or should it be antlib://org.example.package/file.xml antlib:org.example.package/file.xml antlib://org.example.package/antlib.xml In which case, the antlib.xml is just something we patch in on the end if there is no /*.xml file defined at the tail. Thoughts?I guess you did go more into the use case, after your commit ;-)
yeah, i kind of stuck it in as an experiment; we can back out trivially
I'm still not sure I fully follow your logic... but it sounds like you want to load some macros by (ab?)using the antlib mechanism??? Why not simply use <import> to load target-less builds with macro definitions?
I will still be using <import> where needed, but I wanted to define custom antlibs for all the presetdefs and typedefs and scripted things, with the goal being third party projects can reuse them by -lib including the directory. without the full-path antlib stuff we can do that, I just have to create one package/lib.
here is the problem i am trying to deal with http://cvs.sourceforge.net/viewcvs.py/*checkout*/smartfrog/core/antbuild/doc/third_generation_build_process.sxw
Auto-downloading tasks (instead of push, I much prefer pull, where you fail asking the user to run a given target to do the download explicitly) can be handled just the same with an imported build file, no?
I'll probably have a sequence to pull down extra stuff w/ maven as need be
The one think your current use of antlib with -lib gives you is the ability to locate the resource dynamically using the classpath. This could and probably should be handled using an import path (kind of like a vpath) that <import> could use, no? I think this feature has been requested before. It would avoid me having to use an env. var. to locate the imported file as well.
yeah, an import path. interesting idea, though we'd need something on import to refer to a search path or something
Like I said in my other message, I think we should reserve the antlib loading mechanism for load task collection just in the usual way, and use <import>, possibly enhanced, to support what I believe you want. Thoughts? --DD
I am still working out how best to use antlib, and i think others are in the same state. Anything we can do to make this and import work better in big projects is good.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
