ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <gscok...@gmail.com>
Subject Re: specify versions separate from dependencies
Date Thu, 28 Feb 2008 08:52:40 GMT
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.
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.


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



-- 
Gilles Scokart

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message