ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Devienne" <>
Subject RE: Contribution: dependencies task
Date Thu, 26 Aug 2004 15:18:06 GMT
> From: Matt Benson []
> See the following regarding adding your task to the
> list of external tasks:
> As for the defining line of what goes into core Ant, a
> good rule of thumb is that anything that once would
> have been added to the optional tasks portion of Ant
> would NOT be accepted into core Ant today.  :)
> --- Russell Gold <> wrote:
> > OK, I will get back to you with a hosting location.
> > Are new tasks no longer being considered for inclusion
> > in ant? Or if they are, how are decisions made on
> > what to include?

Russell, your task sounds interesting. Automatic dependency
downloading is something important, and although I agree with
Matt and the Ant committers in general to not accept new task
into Ant core or even optional, I feel this particular issue
will down the line warrant being in Ant proper.

That said, it would probably benefit from being available as
an external task first, in order for it to mature and gain
momentum. There are a few issues about dependency downloading
I'd like discussed and addressed, like:

1) Recursive dependencies. Very often, using one dependency (A)
   pulls in other dependencies (B, C, D, etc...) And furthermore,
   using a given version of dependency A often requires given
   a version of its own dependencies (B, C, D, etc...)

   While a first pass basic system that allows you to download
   A v1.2 is useful, it would be better to automatically download
   B v0.12, C v4.5, and D v1.5 as well, since A v1.2 require them.

2) Having a staged repository Path, so a company can setup its
   own intranet-hosted repository searched before the internet
   hosted ibiblio one for example. Caching also comes to mind
   locally and company/group wide.

3) Handling of signatures and licenses. Maven struggled with the
   license issues, for good reasons.

4) Handling of more dynamic dependencies, usually within a given
   organization. For example, we have many components in our
   company with dependencies between each other, all build under
   continuous integration, and thus published all day long. Often,
   we want to update dependencies to the latest available version
   for a given cycle or branch of that code base.

5) Linked with (1), recording of the dependencies used, so that if
   in turn the JAR or component built is published in the repository,
   someone gets the right dependencies of that dependency.

Since the files you attached to your original submissions didn't
go thru (at least for me), I'd recommend you open a BugZilla
enhancement, and attach your code there, at least until you have
a more formal way to host your code. Anyone can then get the code
and contribute/discuss its features and/or enhancements.

Thanks, --DD

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

View raw message