On Thu, 26 Aug 2004 10:18:06 -0500, Dominique Devienne <[EMAIL PROTECTED]> 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 meterware.com repository) tonight once I get out behind my corporate firewall. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
