You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2005/09/09 22:00:11 UTC
Antlib autoloading (was Re: cvs commit:
ant/src/testcases/org/apache/tools/ant/taskdefs AntlibTest.java)
On Fri, 26 Aug 2005, Jose Alberto Fernandez
<ja...@cellectivity.com> wrote:
> Now, for backward compatibility and for convinience in general, one
> would like to be able to put in the -lib directories a bunch of
> antlib jars and that all their tasks get declared automatically as
> part of the default name space.
Steve's approach would allow you to load them into different
namespaces. I don't see that much benefit over <typedef
resource="..."/> in his case, though.
> So, any ideas how this could be acomplished?
Load all resources from META-INF/antlib.xml at startup and process
them, I'd say.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Antlib autoloading
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 9 Sep 2005, Dominique Devienne <dd...@gmail.com> wrote:
> On 9/9/05, Stefan Bodewig <bo...@apache.org> wrote:
>> > So, any ideas how this could be acomplished?
>> Load all resources from META-INF/antlib.xml at startup and process
>> them, I'd say.
>
> But doesn't that go against Ant's tradition to not have auto-magic
> things, but instead spell things out explicitly, usually in the
> build file?
Yes, probably. Even though there is a lot of explicitly invocable
magic that is not visible in the build file either (build.sysclasspath
for example).
> I'd rather we extend <typedef> to accept a <fileset> of AntLib jars
> to load, possibly thru META-INF/antlib.xml, than auto-magically
> loading all possible antlibs visible from the classpath. At least
> you can see it and start looking at the jars it loads.
You can't look at the jars loaded by
xmlns:au="antlib:org.apache.ant.antunit" either.
> How would you know looking at a build file where a task is coming
> from otherwise?
How do you know with a namespace declaration?
> Also, for example, I have quite a few AntLibs which are in ant/lib,
> and thus on Ant's classpath, but I don't use all of them in all my
> builds. They're there because it's our official supercharged
> production Ant distro, but loading all of them in builds that
> require none or just a few is wasteful.
Completely agreed, that's why not enabling autoloading by default is a
good idea. I personally don't want to autoload all antlibs, in
oarticular not all into the default namespace, myself either. I just
commented on how it could be done 8-)
> PS: And BTW, Matt's point about conflict resolution is a good one.
Yes.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Antlib autoloading
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 13 Sep 2005, Steve Loughran <st...@apache.org> wrote:
>> xmlns:foo="antlib:http://example.org/2005/yes#I_can_use_a_catalog_resolver"
>
> this scaers me, as people will assume that we are doing a
> download...
Of the descriptor. Why not? OK, they might expect we download the
lib itself as well.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Antlib autoloading
Posted by Steve Loughran <st...@apache.org>.
Stefan Bodewig wrote:
> On Mon, 12 Sep 2005, Steve Loughran <st...@apache.org> wrote:
>
>
>>I hadnt thought about autoloading; I am happy with explicit loading
>>of stuff into their own namespaces, but want to make it easier for
>>projects to get access to my definitions (or even importable
>>libraries)
>
>
> How do you like this
>
> xmlns:foo="antlib:file:///some/absolute/file.name"
> xmlns:foo="antlib:file:some/relative/file.name"
yes, both interesting
> xmlns:foo="antlib:http://example.org/2005/yes#I_can_use_a_catalog_resolver"
this scaers me, as people will assume that we are doing a download...
> xmlns:foo="antlib:resource:/org/apache/ant/antunit/antlib.xml"
yes, this I like.
I also like DD's idea of letting me import something on the classpath.
Something like
<import resource="projects/something/core.xml" classpathref="app.path" />
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Antlib autoloading
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 12 Sep 2005, Steve Loughran <st...@apache.org> wrote:
> I hadnt thought about autoloading; I am happy with explicit loading
> of stuff into their own namespaces, but want to make it easier for
> projects to get access to my definitions (or even importable
> libraries)
How do you like this
xmlns:foo="antlib:file:///some/absolute/file.name"
xmlns:foo="antlib:file:some/relative/file.name"
xmlns:foo="antlib:http://example.org/2005/yes#I_can_use_a_catalog_resolver"
xmlns:foo="antlib:resource:/org/apache/ant/antunit/antlib.xml"
the last one being the verbise version of
xmlns:foo="antlib:org.apache.ant.antunit
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Antlib autoloading (was Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs
AntlibTest.java)
Posted by Steve Loughran <st...@apache.org>.
Jeffrey E Care wrote:
> I don't normally speak up on the developer list, but I thought this
> discussion could benefit from the experience of a *very large* product
> that uses Ant to build.
>
> We use Ant + our own extensions (Mantis) to build WebSphere Application
> Server (and a good number of the stack products as well). The Mantis
> extensions allow for build modularization both on a fine-grain (called
> "component") and a coarse-grain (called "functional element") scale;
> Mantis also has tasks that manage the dependencies between these modular
> units, for purposes of constructing classpaths, scheduling build order,
> etc.
>
> Given that our build is modular, as you might expect we have many hundreds
> of individual build.xml files in WAS. With that many files it's difficult
> to ensure that everyone is declaring typedefs correctly, so prior to our
> adopting Ant 1.6 we were modifying an Ant 1.5.4 distribution to always
> include the Mantis tasks in oata.tasks.defaults.properties; it was just
> easier for our users that way. Now that we're on an Ant 1.6.5 base we're
> using namespaces + antlibs to make the Mantis tasks available, which IMO
> is better than doing a typedef, but on a large scale it's still difficult
> to ensure that everyone is doing the right thing.
>
> So, with all of that in mind, I really do like the suggestion of
> autoloading type & task definitions from META-INF/antlib.xml; I also
> understand Dominique's concerns about transparency & staying in control.
> Perhaps this behavior could be controlled with a command-line switch, say
> "-autoload" or something along those lines, such that the default behavior
> would be as it is today (i.e. no autoloading), but by specifying the
> switch Ant could search its classpath to discover the antlibs. This would
> also yield a nontrivial performance enhancement, as currently each of our
> modules is effectively reloading our antlib, whereas I would think that
> autoloading would be done once (when Ant is bootstrapped).
>
This sounds like the largest Ant build project I've heard of, excluding
Gump itself, which is so loosely coupled it doesnt really count. We
have, what, 30 build files in ours and I am still struggling to deal
with refactoring it to be more effective. The big problem I have in mine
is that with a single ${root.dir}/common.xml containing most stuff, it
is inordinately brittle. So I am breaking it into separate build files
with lots of cross <imports>, mandatory namespace declarations for all
tasks, presets, etc.
My project rework proposal is here:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/smartfrog/core/antbuild/doc/third_generation_build_process.sxw
for anyone who wants to view and comment.
I hadnt thought about autoloading; I am happy with explicit loading of
stuff into their own namespaces, but want to make it easier for projects
to get access to my definitions (or even importable libraries)
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Antlib autoloading (was Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs
AntlibTest.java)
Posted by Jeffrey E Care <ca...@us.ibm.com>.
I don't normally speak up on the developer list, but I thought this
discussion could benefit from the experience of a *very large* product
that uses Ant to build.
We use Ant + our own extensions (Mantis) to build WebSphere Application
Server (and a good number of the stack products as well). The Mantis
extensions allow for build modularization both on a fine-grain (called
"component") and a coarse-grain (called "functional element") scale;
Mantis also has tasks that manage the dependencies between these modular
units, for purposes of constructing classpaths, scheduling build order,
etc.
Given that our build is modular, as you might expect we have many hundreds
of individual build.xml files in WAS. With that many files it's difficult
to ensure that everyone is declaring typedefs correctly, so prior to our
adopting Ant 1.6 we were modifying an Ant 1.5.4 distribution to always
include the Mantis tasks in oata.tasks.defaults.properties; it was just
easier for our users that way. Now that we're on an Ant 1.6.5 base we're
using namespaces + antlibs to make the Mantis tasks available, which IMO
is better than doing a typedef, but on a large scale it's still difficult
to ensure that everyone is doing the right thing.
So, with all of that in mind, I really do like the suggestion of
autoloading type & task definitions from META-INF/antlib.xml; I also
understand Dominique's concerns about transparency & staying in control.
Perhaps this behavior could be controlled with a command-line switch, say
"-autoload" or something along those lines, such that the default behavior
would be as it is today (i.e. no autoloading), but by specifying the
switch Ant could search its classpath to discover the antlibs. This would
also yield a nontrivial performance enhancement, as currently each of our
modules is effectively reloading our antlib, whereas I would think that
autoloading would be done once (when Ant is bootstrapped).
Just my $0.02.
JEC
--
Jeffrey E. Care (carej@us.ibm.com)
WebSphere v7 Release Engineer
WebSphere Build Tooling Lead (Project Mantis)
Dominique Devienne <dd...@gmail.com> wrote on 09/09/2005 05:57:07 PM:
> On 9/9/05, Stefan Bodewig <bo...@apache.org> wrote:
> > > So, any ideas how this could be acomplished?
> > Load all resources from META-INF/antlib.xml at startup and process
> > them, I'd say.
>
> But doesn't that go against Ant's tradition to not have auto-magic
> things, but instead spell things out explicitly, usually in the build
> file?
>
> I'd rather we extend <typedef> to accept a <fileset> of AntLib jars to
> load, possibly thru META-INF/antlib.xml, than auto-magically loading
> all possible antlibs visible from the classpath. At least you can see
> it and start looking at the jars it loads.
>
> How would you know looking at a build file where a task is coming from
> otherwise?
>
> Also, for example, I have quite a few AntLibs which are in ant/lib,
> and thus on Ant's classpath, but I don't use all of them in all my
> builds. They're there because it's our official supercharged
> production Ant distro, but loading all of them in builds that require
> none or just a few is wasteful.
>
> I personnally want to stay in control of what gets loaded in each
> build. I don't want to prevent others to do it if they fancy it, as
> long as it's not forced on me. --DD
>
> PS: And BTW, Matt's point about conflict resolution is a good one.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
Re: Antlib autoloading (was Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs AntlibTest.java)
Posted by Dominique Devienne <dd...@gmail.com>.
On 9/9/05, Stefan Bodewig <bo...@apache.org> wrote:
> > So, any ideas how this could be acomplished?
> Load all resources from META-INF/antlib.xml at startup and process
> them, I'd say.
But doesn't that go against Ant's tradition to not have auto-magic
things, but instead spell things out explicitly, usually in the build
file?
I'd rather we extend <typedef> to accept a <fileset> of AntLib jars to
load, possibly thru META-INF/antlib.xml, than auto-magically loading
all possible antlibs visible from the classpath. At least you can see
it and start looking at the jars it loads.
How would you know looking at a build file where a task is coming from
otherwise?
Also, for example, I have quite a few AntLibs which are in ant/lib,
and thus on Ant's classpath, but I don't use all of them in all my
builds. They're there because it's our official supercharged
production Ant distro, but loading all of them in builds that require
none or just a few is wasteful.
I personnally want to stay in control of what gets loaded in each
build. I don't want to prevent others to do it if they fancy it, as
long as it's not forced on me. --DD
PS: And BTW, Matt's point about conflict resolution is a good one.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Antlib autoloading
Posted by Matt Benson <gu...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote:
> On Fri, 9 Sep 2005, Matt Benson
> <gu...@yahoo.com> wrote:
>
> >> Load all resources from META-INF/antlib.xml at
> startup and process
> >> them, I'd say.
> >
> > Sounds cool, but what do you do about e.g.
> collisions
> > among tasknames from 3rd-party distributions?
>
> It was Jose Alberto who wanted them in the default
> namespace ;-)
>
> > What is the user's recourse, turn off the warning
> and manually
> > typedef (both)?
>
> Probably. You don't have any chance to resolve this
> any other way
> since the order the resources get discovered and
> might even be
> different on each run (not sure, but it would
> certainly depend on the
> VM).
I suppose, too, that a given project could supply two
versions of antlib.xml: the package-level version
designed for namespaces, and the one in META-INF that
could use a (recommended) e.g. antcontrib=ac-*
convention to reduce the chances of collision. :) Or
would that be too ugly/scary for the world?
-Matt
>
> Stefan
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Antlib autoloading
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 9 Sep 2005, Matt Benson <gu...@yahoo.com> wrote:
>> Load all resources from META-INF/antlib.xml at startup and process
>> them, I'd say.
>
> Sounds cool, but what do you do about e.g. collisions
> among tasknames from 3rd-party distributions?
It was Jose Alberto who wanted them in the default namespace ;-)
> What is the user's recourse, turn off the warning and manually
> typedef (both)?
Probably. You don't have any chance to resolve this any other way
since the order the resources get discovered and might even be
different on each run (not sure, but it would certainly depend on the
VM).
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Antlib autoloading (was Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs AntlibTest.java)
Posted by Matt Benson <gu...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote:
> On Fri, 26 Aug 2005, Jose Alberto Fernandez
> <ja...@cellectivity.com> wrote:
>
> > Now, for backward compatibility and for
> convinience in general, one
> > would like to be able to put in the -lib
> directories a bunch of
> > antlib jars and that all their tasks get declared
> automatically as
> > part of the default name space.
>
> Steve's approach would allow you to load them into
> different
> namespaces. I don't see that much benefit over
> <typedef
> resource="..."/> in his case, though.
>
> > So, any ideas how this could be acomplished?
>
> Load all resources from META-INF/antlib.xml at
> startup and process
> them, I'd say.
Sounds cool, but what do you do about e.g. collisions
among tasknames from 3rd-party distributions? What is
the user's recourse, turn off the warning and manually
typedef (both)?
-Matt
>
> Stefan
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org