ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: Ant source structure and ant*.jar build products
Date Mon, 17 May 2010 04:35:17 GMT
On 2010-05-14, Jesse Glick <> wrote:

> Would be much easier to manage (and possibly more friendly to IDEs) if
> classes were split into several physical source roots.

I'm not a fan of such a source file set up but wouldn't block it either.

> I would also like a clear explanation of what ant-nodeps.jar is
> supposed to be, as distinct from ant.jar.

Initially there was ant.jar and ant-optional.jar with ant.jar holding
the core and all tasks listed as "core tasks" while ant-optional.jar
contained all tasks listed as "optional tasks".  There has never been a
clear rule as to what task should be put into optional and which into
core if the task didn't depend on an external library (if it did, it was

Then we decided to split ant-optional.jar to help people to manage their
classpath for the optional tasks that do require an external library.
ant-nodeps.jar is the bunch of tasks that used to ship in
ant-optional.jar but didn't have any external dependencies.

If you wanted to merge ant.jar with ant-nodeps.jar (which would be fine
with me) we should probably move all tasks included from optional to
core inside the manual as well since the distinction would make even
less sense after that.

> It also seems unpleasant to make parts of the build work only
> conditionally. I think that for any third-party libraries needed by
> the build, we should either include them in lib/optional in the
> Subversion tree (or download from a well-known repository on demand),

I think we already do the later implicitly.

> or move the corresponding tasks to an antlib if nonfree JARs are
> involved.

Even though I like the idea, I'm afraid we won't manage to split out
Antlibs that stood any chance of getting three +1s when it comes to a
release.  We've tried so for VSS and some other of the SCM tasks and
failed.  I doubt we'd be able to manage a JAI or NetREXX Antlib.

> But perhaps there are special considerations here for Linux packagers.

It's more about "historical reasons".  If we want to distribute the
things that we can - legally and following ASF policies - we may still
consider creating a leaner distribution without those libraries.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message