ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harald Braumann <ha...@unheit.net>
Subject Re: specify versions separate from dependencies
Date Thu, 28 Feb 2008 09:34:48 GMT
On Thu, 28 Feb 2008 09:52:40 +0100
"Gilles Scokart" <gscokart@gmail.com> wrote:

> Whaoo, very interresting idea there!
> 
> Here are my tought based on all what has already been said:
> 
> About the name and how to place that in the ivy file :
> Instead of dependencyManagment, what do you think about
> versionManagment ? And what do you think to replace the conflicts
> section with this one? Maybe we could also add a <force> sub-tag
> where we could add some extra-attribute to force.
> 
> 
> About the inclusion :
> As Xavier already said, I'm against the idea of inclusion in the
> repository.  But I'm not in the sources.  I completely understand the
> requirement to put in a central place the version constraints for all
> a project.  So I'm +1 for an inclusion mechanism if we find a good
> one. The problem of such inclusion is that such a file becomes shared
> by multiple module.  It is thus more difficult to get them using some
> file path, and the module reference seems the good aproach.  However,
> when you want to change a dependency, it is very anoying to have to
> publish the file first, and then test it.
> And that's currently a recurent problem when working with multiple
> modules. Sometimes you would like like your dependency meta-data to
> be taken from your source workspace, sometimes you want to take them
> from a repository. 

Ah, the problem of binary vs. source dependencies. So I'm not alone
with my problems, after all. So far I haven't found a good solution
for this (not even theoretically). 

> I think Maven finds an intermdiary aproach saying
> it first search in your source workspace to find the module, then it
> search on your local repository.

I don't know, what you're referring to, here. Maven only uses
installed/deployed artifacts. The eclipse plugin, however, which
creates .project and .classpath files for eclipse from pom files, can
create source references. But this only works, if the pom file in the
dependee's source directory has the same version as is specified in the
dependency of the depender. So whenever you change the version of one
artifact, you have to change dependencies in all depending artifact.
I've hacked the eclipse plugin to ignore the version, but this leads to
inconsistencies, as it now depends on where you build: from eclipse or
from command line. 

> And about the conflict managment:
> What will happen when two versionManagment are in conflicts?
> I'm wondering if the scope of the versionManagment shouldn't be
> limited to the root module that you are resolving.  That would
> greatly simplify things.  Is it too simplist?  I'm not sure.  But
> that probably means that the published ivy files should contains some
> result of the dependncy managment resoluition (which is something
> that is regularily suggested anyway).

If the version overrides are resolved transitively, then I think the
only sensible thing to do in this case is to use nearest. If some kind
of parent mechanism is used, there can only be one parent, so there
won't be any conflicts with nearest. If you can specify overrides in
multiple places, like in the ivy file as well as in the settings file,
as was suggested by Shawn, then a strict precedence has to be defined
(settings file overrides ivy file).

harry

Mime
View raw message