ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell Gold <>
Subject Re: Contribution: dependencies task
Date Thu, 26 Aug 2004 16:10:40 GMT
On Thu, 26 Aug 2004 10:18:06 -0500, Dominique Devienne
<> wrote:
> 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.

A topic for discussion on its own. To me, the bigger issue is
dependency compatibility. My project may wish to use B v0.15 since it
has some features I need, even though A v1.2 only uses B v0.12. What I
thought would be needed is a compatibility checker which scans through
the build files of all the included projects to see what they are
including and warns of problems, rather than presuming to know what
else to download. But that is probably a higher-level function.

> 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.

Already present. The system property ant.remote.repository accepts a
comma-separated list of repositories and searches them in order.  The
unit-test addresses this feature.
> 3) Handling of signatures and licenses. Maven struggled with the
>    license issues, for good reasons.

Can you tell me more about these issues?

> 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.

I have used that policy at previous employers. We often found it to be
problematic, as a group would release an update to a dependant jar
that broke our build or tests. So we adopted the policy that each
group is responsible for selecting the versions of the dependencies it
uses.  But being able to try the latest version automatically has its
merits - that's what gump does, isn't? It's not obvious to me the best
way to handle that.

> 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.

That's what this task is about. Since it specifies the dependencies,
anybody looking at the build.xml can see exactly which ones were used.
It would be nice to include something in the jar manifest which
identifies the minimum versions of its dependencies needed, but it is
not obvious to me how to do that.

> 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.

I can do that; alternately, I could create a project in the HttpUnit
repository (or my private repository) tonight once I get
out behind my corporate firewall.

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

View raw message