ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: antlib loading in typedef
Date Fri, 26 Aug 2005 15:55:04 GMT
Dominique Devienne wrote:
>>From: Steve Loughran []
>>One change I have also checked in to is some extra logic
>>for naming antlibs. Instead of just
>>	antlib: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
>>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
>>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.
> 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*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:
For additional commands, e-mail:

View raw message