ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: specify versions separate from dependencies
Date Thu, 28 Feb 2008 10:10:32 GMT
On Thu, Feb 28, 2008 at 9:52 AM, Gilles Scokart <> 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 ?

Sounds much better. But does this still make sense if we allow to override
arbitrary extra attributes, and branch?

> And what do you think to replace the conflicts section with this one?

I'm really in favor of merging the two, they are very related. But we still
have to find a good syntax.

> Maybe we could also add a <force> sub-tag where we could add some
> extra-attribute to force.

Why not, but in this case I would keep it consistent, and put revision
forcing here too. Maybe an example of the syntax you envision would be more

> About the inclusion :
> As Xavier already said, I'm against the idea of inclusion in the
> repository.  But I'm not in the sources.

So I think we share the same opinion. Great!

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

This is not much different from the settings file loading. We provide file
based or url based loading, and until now people find their way with that.
Maybe we could stick with that to start, and then review the loading
mechanism. If we find a good loading mechanism, I think we should apply it
to both inclusion and settings.

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.

Agreed too.

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

Exactly. And this is not only true for module metadata, but also for
artifacts. To go even further, in multi module development, it would be even
better to be able to "understand" exploded artifacts (being able to use a
"classes" directory as an equivalent of a jar). But I think we can keep
these subjects separated, and address one thing at a time.

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

But you need conventions in your workspace layout to do so, and we haven't
in Ivy. IMHO this could be adressed by a kind of publish which just tells
Ivy where the sources for the module and its (possibly exploded) artifacts
are. Then Ivy would be use this source location as a kind of local
repository for one module only. But once again I think we can split the
requirements and ideas, and focus on one thing at a time.

> And about the conflict managment:
> What will happen when two versionManagment are in conflicts?

I think we should use the conflict manager in this case. I don't it's
simple, but I think it makes sense.

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

Indeed, storing the dependency closure in the published Ivy file would
simplify the dependency resolution process, and it would greatly improve
performance too. So I'm in favor of this improvement too.
That being said, I'm wondering if we could make this mandatory in the case
of usage of versionManagement section. This would mean that we wouldn't
support version overriding in ivy files in repository, only dependency
closure. But I don't know which way we should go... Indeed I think we have
to support version overriding in repository files to be compatible with
maven2 (still have to test to see how conflicts are handled in this case).
So I'd rather go with supporting version overriding in repository files, and
consider the publishing and usage of dependency closure a separate feature.


> --
> Gilles Scokart

Xavier Hanin - Independent Java Consultant

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