You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Harald Braumann <ha...@unheit.net> on 2008/02/26 18:46:25 UTC
specify versions separate from dependencies
Hi,
is it possible with ivy to specify the versions of dependencies
separate from the actual dependency specification? Similar to the
<dependencyMangement> section in maven's parent pom?
Regards,
harry
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Wed, Feb 27, 2008 at 7:26 PM, Niklas Matthies <ml...@nmhq.net>
wrote:
> On Wed 2008-02-27 at 18:48h, Xavier Hanin wrote on ivy-user:
> > On Wed, Feb 27, 2008 at 6:11 PM, Niklas Matthies wrote:
> :
> > > I added a comment to the issue. Personally I haven't had the need for
> > > something like that in Ivy yet. It's just that I hate seeing features
> > > being added that let you do something (e.g. "override") to just one
> > > particular type of object (e.g. "revision of a transitive
> dependency"),
> > > and not for all objects where it makes sense. :)
> >
> > I usually agree, if I can envision some kind of use case for the
> > generalization. In this particular case I don't see what we could
> override
> > besides the revision of a transitive dependency. Do you have any idea?
>
> How about forcing a particular configuration or branch or some extra
> attribute for a (set of) transitively dependent module(s)?
Forcing the branch or some extra attribute makes sense, indeed. Forcing the
configuration mapping sounds dangerous to me.
Xavier
>
> Or overriding a (default or non-default) configuration mapping.
> There's probably more if I look hard enough. ;)
>
> -- Niklas Matthies
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Niklas Matthies <ml...@nmhq.net>.
On Wed 2008-02-27 at 18:48h, Xavier Hanin wrote on ivy-user:
> On Wed, Feb 27, 2008 at 6:11 PM, Niklas Matthies wrote:
:
> > I added a comment to the issue. Personally I haven't had the need for
> > something like that in Ivy yet. It's just that I hate seeing features
> > being added that let you do something (e.g. "override") to just one
> > particular type of object (e.g. "revision of a transitive dependency"),
> > and not for all objects where it makes sense. :)
>
> I usually agree, if I can envision some kind of use case for the
> generalization. In this particular case I don't see what we could override
> besides the revision of a transitive dependency. Do you have any idea?
How about forcing a particular configuration or branch or some extra
attribute for a (set of) transitively dependent module(s)?
Or overriding a (default or non-default) configuration mapping.
There's probably more if I look hard enough. ;)
-- Niklas Matthies
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Wed, Feb 27, 2008 at 6:11 PM, Niklas Matthies <ml...@nmhq.net>
wrote:
> On Wed 2008-02-27 at 17:00h, Xavier Hanin wrote on ivy-user:
> > On Wed, Feb 27, 2008 at 4:42 PM, Niklas Matthies <ml...@nmhq.net>
> > wrote:
> >
> > > As for how to implement this in Ivy, how about:
> > >
> > > - Provide an inclusion facility for ivy files to semantically
> > > include/merge the contents of some other ivy file, similar as
> > > "include" for the settings files. Possibly add an attribute to
> > > choose what to do in case of conflicting/non-mergeable specs.
> >
> > Vote for IVY-742! As you can see, Gilles is not in favor of supporting
> this
> > kind of mechanism in Ivy. But Ivy is community driven, so your vote and
> > opinion really count.
>
> I added a comment to the issue. Personally I haven't had the need for
> something like that in Ivy yet. It's just that I hate seeing features
> being added that let you do something (e.g. "override") to just one
> particular type of object (e.g. "revision of a transitive dependency"),
> and not for all objects where it makes sense. :)
I usually agree, if I can envision some kind of use case for the
generalization. In this particular case I don't see what we could override
besides the revision of a transitive dependency. Do you have any idea?
> > > IMO *any* configuration/specification file format ought to have such
> > > a mechanism.
> >
> > The problem with this kind of mechanism is that it make things more
> complex
> > to understand, and more complex to parse too.
>
> Well, the merging should happen after the actual parsing (but maybe
> that's what you mean).
The problem is to parse the included file you need to locate it. and with
Ivy flexible repository settings it's not always easy to know where the
included file is located.
> > IMO, a good compromise would be to disallow inclusion for ivy files
> > in the repository. Having selfcontained metadata in the repository
> > makes things much easier, especially for external parsing and
> > analysis.
>
>
> The resolved ivy file (as produced by the deliver task) probably
> should textually contain the included settings. Apart from that I
> wouldn't necessarily bother to disallow inclusion in retrieved ivy
> files (similar as for dynamic revisions). The question is probably
> more how such an include reference would look like. A relative file
> path? A module reference?
That's my point. Using a relative path will make the publication itself
difficult. If we use a module reference, we are getting closer to the parent
mechanism in maven 2. But then, when the file is not published yet, do you
have to publish the included file in the repository? If you don't, how does
Ivy locate it, if it's only a module reference? That's really tricky, and
that's why I'd really prefer not supporting inclusion/parent in the
repository.
Xavier
>
>
> > > - Add the possibility to specify any kind of ivy file tags under the
> > > "module" tag of a settings file, to be semantically injected into
> > > the ivy files of all matched modules. Basically a "reverse-include".
> >
> > I'm not a big fan of mixing too much of resolution metadata between
> settings
> > and ivy files. I much prefer keeping this kind of things in ivy files.
> If we
> > support some kind of parent mechanism and a dependencyManagement
> feature, we
> > cover the need, and still keep most resolution metadata in Ivy files,
> and
> > thus in the repository.
>
> I guess I agree, except for the specific "dependencyManagement"
> feature. See my next post.
>
> -- Niklas Matthies
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Niklas Matthies <ml...@nmhq.net>.
On Wed 2008-02-27 at 17:00h, Xavier Hanin wrote on ivy-user:
> On Wed, Feb 27, 2008 at 4:42 PM, Niklas Matthies <ml...@nmhq.net>
> wrote:
>
> > As for how to implement this in Ivy, how about:
> >
> > - Provide an inclusion facility for ivy files to semantically
> > include/merge the contents of some other ivy file, similar as
> > "include" for the settings files. Possibly add an attribute to
> > choose what to do in case of conflicting/non-mergeable specs.
>
> Vote for IVY-742! As you can see, Gilles is not in favor of supporting this
> kind of mechanism in Ivy. But Ivy is community driven, so your vote and
> opinion really count.
I added a comment to the issue. Personally I haven't had the need for
something like that in Ivy yet. It's just that I hate seeing features
being added that let you do something (e.g. "override") to just one
particular type of object (e.g. "revision of a transitive dependency"),
and not for all objects where it makes sense. :)
> > IMO *any* configuration/specification file format ought to have such
> > a mechanism.
>
> The problem with this kind of mechanism is that it make things more complex
> to understand, and more complex to parse too.
Well, the merging should happen after the actual parsing (but maybe
that's what you mean).
> IMO, a good compromise would be to disallow inclusion for ivy files
> in the repository. Having selfcontained metadata in the repository
> makes things much easier, especially for external parsing and
> analysis.
The resolved ivy file (as produced by the deliver task) probably
should textually contain the included settings. Apart from that I
wouldn't necessarily bother to disallow inclusion in retrieved ivy
files (similar as for dynamic revisions). The question is probably
more how such an include reference would look like. A relative file
path? A module reference?
> > - Add the possibility to specify any kind of ivy file tags under the
> > "module" tag of a settings file, to be semantically injected into
> > the ivy files of all matched modules. Basically a "reverse-include".
>
> I'm not a big fan of mixing too much of resolution metadata between settings
> and ivy files. I much prefer keeping this kind of things in ivy files. If we
> support some kind of parent mechanism and a dependencyManagement feature, we
> cover the need, and still keep most resolution metadata in Ivy files, and
> thus in the repository.
I guess I agree, except for the specific "dependencyManagement"
feature. See my next post.
-- Niklas Matthies
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Wed, Feb 27, 2008 at 4:42 PM, Niklas Matthies <ml...@nmhq.net>
wrote:
> As for how to implement this in Ivy, how about:
>
> - Provide an inclusion facility for ivy files to semantically
> include/merge the contents of some other ivy file, similar as
> "include" for the settings files. Possibly add an attribute to
> choose what to do in case of conflicting/non-mergeable specs.
Vote for IVY-742! As you can see, Gilles is not in favor of supporting this
kind of mechanism in Ivy. But Ivy is community driven, so your vote and
opinion really count.
> IMO *any* configuration/specification file format ought to have such
> a mechanism.
The problem with this kind of mechanism is that it make things more complex
to understand, and more complex to parse too. IMO, a good compromise would
be to disallow inclusion for ivy files in the repository. Having
selfcontained metadata in the repository makes things much easier,
especially for external parsing and analysis.
>
> - Add the possibility to specify any kind of ivy file tags under the
> "module" tag of a settings file, to be semantically injected into
> the ivy files of all matched modules. Basically a "reverse-include".
I'm not a big fan of mixing too much of resolution metadata between settings
and ivy files. I much prefer keeping this kind of things in ivy files. If we
support some kind of parent mechanism and a dependencyManagement feature, we
cover the need, and still keep most resolution metadata in Ivy files, and
thus in the repository.
Xavier
>
>
> As above, possibly add an attribute to choose what to do in case of
> conflicting/non-mergeable specs.
>
> Something along these lines would be more generic/orthogonal/flexible
> than adding a dedicated construct for the specific use case here.
>
> -- Niklas Matthies
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Niklas Matthies <ml...@nmhq.net>.
As for how to implement this in Ivy, how about:
- Provide an inclusion facility for ivy files to semantically
include/merge the contents of some other ivy file, similar as
"include" for the settings files. Possibly add an attribute to
choose what to do in case of conflicting/non-mergeable specs.
IMO *any* configuration/specification file format ought to have such
a mechanism.
- Add the possibility to specify any kind of ivy file tags under the
"module" tag of a settings file, to be semantically injected into
the ivy files of all matched modules. Basically a "reverse-include".
As above, possibly add an attribute to choose what to do in case of
conflicting/non-mergeable specs.
Something along these lines would be more generic/orthogonal/flexible
than adding a dedicated construct for the specific use case here.
-- Niklas Matthies
Re: specify versions separate from dependencies
Posted by Harald Braumann <ha...@unheit.net>.
On Thu, 28 Feb 2008 09:52:40 +0100
"Gilles Scokart" <gs...@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
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Thu, Feb 28, 2008 at 9:52 AM, Gilles Scokart <gs...@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 ?
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
explicit?
>
>
>
> 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.
Agreed.
>
> 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.
Xavier
>
>
>
> --
> Gilles Scokart
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Gilles Scokart <gs...@gmail.com>.
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
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
Nascif,
You're not the first one to ask for this, Shawn already expressed the same
need. But I'm not personnally in favor of this: I prefer to keep this in the
Ivy file to keep dependency data in the repository and not in the settings.
My proposition would rather to implement an inheritance mechanism as maven
provides: All you ivy files could inherit from a central ivy file, which
would define the overrides. In this case we would easily be able to publish
a self contained ivy file, to ease later parsing of information. Would this
be enough, or do you really see an added value in supporting this in
settings files?
BTW, please note that what I've introduced here is for overriding
information when there is no conflict. To deal with conflicts, I encourage
using the existing conflicts sections in Ivy files (or in the settings). The
new override mechanism works differently, it makes all dependees which
themselves depend on the overriden dependency behave exactly as if they had
declared a dependency on the overriden version. So this won't appear as a
conflict in dependendees. If several modules make use of this feature in the
same set of dependencies, then Ivy will have to deal with that using the
conflict manager, exactly as if the dependency declared where the overriden
one.
Xavier
On Mon, Mar 24, 2008 at 8:07 PM, Nascif Abousalh-Neto <
Nascif.AbousalhNeto@sas.com> wrote:
> To elaborate on Jim's point, it is important to consider mechanisms that
> allow for centralized management of this new feature.
>
> I can see how this feature would be used to override the dependency of
> commonly used jars. For companies with hundreds of projects using those
> jars, having a single place to manage overrides would be immensely valuable.
>
> Having a similar session on the ivy settings files (that you could
> customize with variables) providing default values that the ivy-module could
> refine would be a way.
>
> /Nascif
>
>
> -----Original Message-----
> From: Jim Adams [mailto:Jim.Adams@sas.com]
> Sent: Monday, March 24, 2008 2:48 PM
> To: ivy-user@ant.apache.org
> Subject: RE: specify versions separate from dependencies
>
> Is there any way to include this from another file? What I am thinking of
> is that we have a properties file filled with the default versions of third
> party dependencies that our build wants to use. We have different build
> tracks, corresponding to different installable portions of our system, where
> people may decide that they want to override the original third party
> dependencies. It seems that this would be possible with this system. I am
> concerned that I will end up with conflicts, however, and not know it nor
> really understand the implications of these conflicts.
>
> > -----Original Message-----
> > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > Sent: Monday, March 24, 2008 2:31 PM
> > To: ivy-user@ant.apache.org
> > Subject: Re: specify versions separate from dependencies
> >
> > I've started working on this, and come close to a solution. To finalize
> my
> > work, we need to decide upon the syntax we want to use in Ivy files to
> > support transitive dependency override mechanism.
> >
> > After some more thoughts on the feature and how it relates to existing
> Ivy
> > features, I think we now have 3 different ways to influence transitive
> > dependencies in an Ivy file:
> > - transitive dependency exclusion (IVY-431), introduced in 2.0.0-alpha1.
> > This feature relies on an 'exclude' tag directly under the
> 'dependencies'
> > element.
> > - setting specific conflict managers for transitive dependencies. This
> > relies on a 'conflicts' element and its child elements 'manager'.
> > - overriding version and/or branch of transitive dependencies. In the
> > implementation, I've opened the door to more feature than that, by
> > implementing a dependency descriptor mediator mechanism. Whenever we
> load a
> > module descriptor dependency descriptors to resolve them, we first ask
> all
> > the dependers to mediate each dependency descriptor. Then we use the
> > mediated dependency descriptor to resolve the dependency, instead of the
> > original one. For the moment I've only implemented one mediator, called
> > override. But we could later imagine other kinds of mediation which
> happens
> > before actual dependency resolution. For the moment I've used this
> syntax
> > for this new feature:
> > <engine-hints>
> > <mediation>
> > <override org="yourorg" module=".*1" matcher="regexp"
> > branch="BRANCH" rev="1.0" />
> > </mediation>
> > </engine-hints>
> > This section is put directly under ivy-module element. What I would like
> to
> > do is group the three kind of transitive dependencies hints we can give
> to
> > the resolve engine in an ivy file. I'm still wondering what is the best
> > syntax, and if we can afford deprecating the syntax of conflicts and
> module
> > wide exclude. If we agree to deprecate them, here's one idea for the new
> > syntax:
> > <ivy-module>
> > <dependencies>
> > <dependency ... />
> > <dependency ... />
> > ...
> > <hints>
> > <exclude org="" module="" matcher="" ... />
> > <conflict org="" module="" matcher="" rev|manager="" />
> > <override org="" module="" matcher="" branch="" rev="" />
> > </hints>
> > </dependencies>
> > </ivy-module>
> > The conflict tag is similar to the current conflicts/manager tag, except
> > that the 'name' attribute is replaced by 'manager'.
> > All three kind of hints share the same attribute triple (org - module -
> > matcher). The usage of this uple is slightly different in exclude, where
> it
> > also applied to other attributes, such as artifact (to name the
> artifacts to
> > exclude transitively).
> >
> > Another approach would be to put the hints section directly under
> ivy-module
> > instead of under dependencies (as it's the case for conflicts/manager
> > today). I think I prefer the former approach I propose.
> >
> > This is open to discussion, please give your feedback, once 2.0 will be
> out
> > we won't be able to go back.
> >
> > Xavier
> >
> > On Wed, Feb 27, 2008 at 8:30 PM, Harald Braumann <ha...@unheit.net>
> wrote:
> >
> > > On Wed, 27 Feb 2008 14:23:50 +0100
> > > "Xavier Hanin" <xa...@gmail.com> wrote:
> > >
> > > > Could you open an issue about that?
> > >
> > > Here it is: https://issues.apache.org/jira/browse/IVY-753
> > >
> > > harry
> > >
> >
> >
> >
> > --
> > Xavier Hanin - Independent Java Consultant
> > http://xhab.blogspot.com/
> > http://ant.apache.org/ivy/
> > http://www.xoocode.org/
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
RE: specify versions separate from dependencies
Posted by Jim Adams <Ji...@sas.com>.
While on this subject, is there a way to centrally manage the list of configurations available in an ivy file? Personally I would have created a default set of configurations in the settings file and then allowed the ivy files to modify the defaults.
> -----Original Message-----
> From: Nascif Abousalh-Neto [mailto:Nascif.AbousalhNeto@sas.com]
> Sent: Monday, March 24, 2008 3:08 PM
> To: ivy-user@ant.apache.org
> Subject: RE: specify versions separate from dependencies
>
> To elaborate on Jim's point, it is important to consider mechanisms that allow for centralized management of
> this new feature.
>
> I can see how this feature would be used to override the dependency of commonly used jars. For companies with
> hundreds of projects using those jars, having a single place to manage overrides would be immensely valuable.
>
> Having a similar session on the ivy settings files (that you could customize with variables) providing default
> values that the ivy-module could refine would be a way.
>
> /Nascif
>
>
> -----Original Message-----
> From: Jim Adams [mailto:Jim.Adams@sas.com]
> Sent: Monday, March 24, 2008 2:48 PM
> To: ivy-user@ant.apache.org
> Subject: RE: specify versions separate from dependencies
>
> Is there any way to include this from another file? What I am thinking of is that we have a properties file
> filled with the default versions of third party dependencies that our build wants to use. We have different
> build tracks, corresponding to different installable portions of our system, where people may decide that they
> want to override the original third party dependencies. It seems that this would be possible with this system. I
> am concerned that I will end up with conflicts, however, and not know it nor really understand the implications
> of these conflicts.
>
> > -----Original Message-----
> > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > Sent: Monday, March 24, 2008 2:31 PM
> > To: ivy-user@ant.apache.org
> > Subject: Re: specify versions separate from dependencies
> >
> > I've started working on this, and come close to a solution. To finalize my
> > work, we need to decide upon the syntax we want to use in Ivy files to
> > support transitive dependency override mechanism.
> >
> > After some more thoughts on the feature and how it relates to existing Ivy
> > features, I think we now have 3 different ways to influence transitive
> > dependencies in an Ivy file:
> > - transitive dependency exclusion (IVY-431), introduced in 2.0.0-alpha1.
> > This feature relies on an 'exclude' tag directly under the 'dependencies'
> > element.
> > - setting specific conflict managers for transitive dependencies. This
> > relies on a 'conflicts' element and its child elements 'manager'.
> > - overriding version and/or branch of transitive dependencies. In the
> > implementation, I've opened the door to more feature than that, by
> > implementing a dependency descriptor mediator mechanism. Whenever we load a
> > module descriptor dependency descriptors to resolve them, we first ask all
> > the dependers to mediate each dependency descriptor. Then we use the
> > mediated dependency descriptor to resolve the dependency, instead of the
> > original one. For the moment I've only implemented one mediator, called
> > override. But we could later imagine other kinds of mediation which happens
> > before actual dependency resolution. For the moment I've used this syntax
> > for this new feature:
> > <engine-hints>
> > <mediation>
> > <override org="yourorg" module=".*1" matcher="regexp"
> > branch="BRANCH" rev="1.0" />
> > </mediation>
> > </engine-hints>
> > This section is put directly under ivy-module element. What I would like to
> > do is group the three kind of transitive dependencies hints we can give to
> > the resolve engine in an ivy file. I'm still wondering what is the best
> > syntax, and if we can afford deprecating the syntax of conflicts and module
> > wide exclude. If we agree to deprecate them, here's one idea for the new
> > syntax:
> > <ivy-module>
> > <dependencies>
> > <dependency ... />
> > <dependency ... />
> > ...
> > <hints>
> > <exclude org="" module="" matcher="" ... />
> > <conflict org="" module="" matcher="" rev|manager="" />
> > <override org="" module="" matcher="" branch="" rev="" />
> > </hints>
> > </dependencies>
> > </ivy-module>
> > The conflict tag is similar to the current conflicts/manager tag, except
> > that the 'name' attribute is replaced by 'manager'.
> > All three kind of hints share the same attribute triple (org - module -
> > matcher). The usage of this uple is slightly different in exclude, where it
> > also applied to other attributes, such as artifact (to name the artifacts to
> > exclude transitively).
> >
> > Another approach would be to put the hints section directly under ivy-module
> > instead of under dependencies (as it's the case for conflicts/manager
> > today). I think I prefer the former approach I propose.
> >
> > This is open to discussion, please give your feedback, once 2.0 will be out
> > we won't be able to go back.
> >
> > Xavier
> >
> > On Wed, Feb 27, 2008 at 8:30 PM, Harald Braumann <ha...@unheit.net> wrote:
> >
> > > On Wed, 27 Feb 2008 14:23:50 +0100
> > > "Xavier Hanin" <xa...@gmail.com> wrote:
> > >
> > > > Could you open an issue about that?
> > >
> > > Here it is: https://issues.apache.org/jira/browse/IVY-753
> > >
> > > harry
> > >
> >
> >
> >
> > --
> > Xavier Hanin - Independent Java Consultant
> > http://xhab.blogspot.com/
> > http://ant.apache.org/ivy/
> > http://www.xoocode.org/
RE: specify versions separate from dependencies
Posted by Nascif Abousalh-Neto <Na...@sas.com>.
To elaborate on Jim's point, it is important to consider mechanisms that allow for centralized management of this new feature.
I can see how this feature would be used to override the dependency of commonly used jars. For companies with hundreds of projects using those jars, having a single place to manage overrides would be immensely valuable.
Having a similar session on the ivy settings files (that you could customize with variables) providing default values that the ivy-module could refine would be a way.
/Nascif
-----Original Message-----
From: Jim Adams [mailto:Jim.Adams@sas.com]
Sent: Monday, March 24, 2008 2:48 PM
To: ivy-user@ant.apache.org
Subject: RE: specify versions separate from dependencies
Is there any way to include this from another file? What I am thinking of is that we have a properties file filled with the default versions of third party dependencies that our build wants to use. We have different build tracks, corresponding to different installable portions of our system, where people may decide that they want to override the original third party dependencies. It seems that this would be possible with this system. I am concerned that I will end up with conflicts, however, and not know it nor really understand the implications of these conflicts.
> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: Monday, March 24, 2008 2:31 PM
> To: ivy-user@ant.apache.org
> Subject: Re: specify versions separate from dependencies
>
> I've started working on this, and come close to a solution. To finalize my
> work, we need to decide upon the syntax we want to use in Ivy files to
> support transitive dependency override mechanism.
>
> After some more thoughts on the feature and how it relates to existing Ivy
> features, I think we now have 3 different ways to influence transitive
> dependencies in an Ivy file:
> - transitive dependency exclusion (IVY-431), introduced in 2.0.0-alpha1.
> This feature relies on an 'exclude' tag directly under the 'dependencies'
> element.
> - setting specific conflict managers for transitive dependencies. This
> relies on a 'conflicts' element and its child elements 'manager'.
> - overriding version and/or branch of transitive dependencies. In the
> implementation, I've opened the door to more feature than that, by
> implementing a dependency descriptor mediator mechanism. Whenever we load a
> module descriptor dependency descriptors to resolve them, we first ask all
> the dependers to mediate each dependency descriptor. Then we use the
> mediated dependency descriptor to resolve the dependency, instead of the
> original one. For the moment I've only implemented one mediator, called
> override. But we could later imagine other kinds of mediation which happens
> before actual dependency resolution. For the moment I've used this syntax
> for this new feature:
> <engine-hints>
> <mediation>
> <override org="yourorg" module=".*1" matcher="regexp"
> branch="BRANCH" rev="1.0" />
> </mediation>
> </engine-hints>
> This section is put directly under ivy-module element. What I would like to
> do is group the three kind of transitive dependencies hints we can give to
> the resolve engine in an ivy file. I'm still wondering what is the best
> syntax, and if we can afford deprecating the syntax of conflicts and module
> wide exclude. If we agree to deprecate them, here's one idea for the new
> syntax:
> <ivy-module>
> <dependencies>
> <dependency ... />
> <dependency ... />
> ...
> <hints>
> <exclude org="" module="" matcher="" ... />
> <conflict org="" module="" matcher="" rev|manager="" />
> <override org="" module="" matcher="" branch="" rev="" />
> </hints>
> </dependencies>
> </ivy-module>
> The conflict tag is similar to the current conflicts/manager tag, except
> that the 'name' attribute is replaced by 'manager'.
> All three kind of hints share the same attribute triple (org - module -
> matcher). The usage of this uple is slightly different in exclude, where it
> also applied to other attributes, such as artifact (to name the artifacts to
> exclude transitively).
>
> Another approach would be to put the hints section directly under ivy-module
> instead of under dependencies (as it's the case for conflicts/manager
> today). I think I prefer the former approach I propose.
>
> This is open to discussion, please give your feedback, once 2.0 will be out
> we won't be able to go back.
>
> Xavier
>
> On Wed, Feb 27, 2008 at 8:30 PM, Harald Braumann <ha...@unheit.net> wrote:
>
> > On Wed, 27 Feb 2008 14:23:50 +0100
> > "Xavier Hanin" <xa...@gmail.com> wrote:
> >
> > > Could you open an issue about that?
> >
> > Here it is: https://issues.apache.org/jira/browse/IVY-753
> >
> > harry
> >
>
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Mon, Mar 31, 2008 at 2:30 PM, Johannes Stamminger <
Johannes.Stamminger@astrium.eads.net> wrote:
>
> On Monday 31 March 2008, Xavier Hanin wrote:
> > Exclude can already be applied per dependency, it's even the first case
> of
> > exclusion supported by Ivy. In this case, the module or set of modules
> is
> > excluded only from the transitive set of dependencies resolved for the
> > direct dependency on which the exclusion is defined, and has no impact
> on
> > other dependencies. So if you want to make sure you don't get one
> module,
> > you should use global exclude.
>
> Same for override? The usecase would look very similar to the one for
> exclude.
I agree, the use case is pretty similar, so it would make sense to support
override per dependency too. I'm not sure we will have enough time to
implement this in 2.0.0 though.
Xavier
>
>
> Johannes Stamminger
> --
> Johannes.Stamminger@Astrium.EADS.net [2FE783D0 http://wwwkeys.PGP.net]
> ------ ----<--{(@ ------------------ EADS ASTRIUM
> Koenigsberger Str. 17, 28857 Barrien Ground System Eng. (TE55)
> +49 4242 169582 (Tel + FAX) Airbus Allee 1, 28199 Bremen
> +49 174 7731593 (Mobile) +49 421 539 4152 (Tel) / 4378 (FAX)
>
> This email (including any attachments) may contain confidential and/or
> privileged information or information otherwise protected from disclosure.
> If you are not the intended recipient, please notify the sender immediately,
> do not copy this message or any attachments and do not use it for any
> purpose or disclose its content to any person, but delete this message and
> any attachments from your system. Astrium disclaims any and all liability if
> this email transmission was virus corrupted, altered or falsified.
> ---------------------------------------------------------
> Astrium GmbH Vorsitzender des Aufsichtsrates: Thomas Mueller -
> Geschaeftsfuehrung: Evert Dudok (Vorsitzender), Dr. Reinhold Lutz, Pablo
> Salame Fischer, Guenter Stamerjohanns
> Sitz der Gesellschaft: Muenchen - Registergericht: Amtsgericht Muenchen,
> HRB Nr. 107 647
>
> Weitere Informationen ueber EADS Astrium @ http://www.astrium.eads.net/
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Johannes Stamminger <Jo...@astrium.eads.net>.
On Monday 31 March 2008, Xavier Hanin wrote:
> Exclude can already be applied per dependency, it's even the first case of
> exclusion supported by Ivy. In this case, the module or set of modules is
> excluded only from the transitive set of dependencies resolved for the
> direct dependency on which the exclusion is defined, and has no impact on
> other dependencies. So if you want to make sure you don't get one module,
> you should use global exclude.
Same for override? The usecase would look very similar to the one for exclude.
Johannes Stamminger
--
Johannes.Stamminger@Astrium.EADS.net [2FE783D0 http://wwwkeys.PGP.net]
------ ----<--{(@ ------------------ EADS ASTRIUM
Koenigsberger Str. 17, 28857 Barrien Ground System Eng. (TE55)
+49 4242 169582 (Tel + FAX) Airbus Allee 1, 28199 Bremen
+49 174 7731593 (Mobile) +49 421 539 4152 (Tel) / 4378 (FAX)
This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Astrium disclaims any and all liability if this email transmission was virus corrupted, altered or falsified.
---------------------------------------------------------
Astrium GmbH Vorsitzender des Aufsichtsrates: Thomas Mueller - Geschaeftsfuehrung: Evert Dudok (Vorsitzender), Dr. Reinhold Lutz, Pablo Salame Fischer, Guenter Stamerjohanns
Sitz der Gesellschaft: Muenchen - Registergericht: Amtsgericht Muenchen, HRB Nr. 107 647
Weitere Informationen ueber EADS Astrium @ http://www.astrium.eads.net/
Re: [LIKELY_SPAM]Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Mon, Mar 31, 2008 at 12:17 PM, Niklas Matthies <ml...@nmhq.net>
wrote:
> On Mon 2008-03-31 at 08:39h, Johannes Stamminger wrote on ivy-user:
> > On Saturday 29 March 2008, Gilles Scokart wrote:
> > > On 28/03/2008, Johannes Stamminger <
> Johannes.Stamminger@astrium.eads.net> wrote:
> :
> > > > the exclude and override I could imagine that it would make sense
> to
> > > > specify them per dependency - not only globally for all dependencies
> ...
> > > > ?
> > >
> > > Why would you exclude or overwrite it for one dependency but not for
> the
> > > others?
> :
> > P1 -> L1 -> L2
> > and
> > P1 -> L3 -> L2
> >
> > With the global exclude L2 still is not in P1 though it is needed
> > now. With specifying it only for the dependency to L1, people in P1
> > get triggered to analyse the dependency again (when detecting the
> > newly included L2). With specifying it globally one runs into
> > problems in worst case (dynamic load of L2 in L1) only very late.
>
> I wonder how the semantics is intended to be anyway (by Ivy).
> What if L1 excludes (some revisions of) L2 because it isn't compatible
> with them? Can L3 cause such in incompatible revision to be included
> anyway? What if L3 uses <override>?
>
> In that light, it seems to me that applying exclude/override globally
> is the only thing that makes sense. The logic by which Ivy prunes
> dependency subtrees is based on the assumption that it doesn't matter
> in which order conflicts are considered; that the result will be the
> same regardless of the order. Exclude/override/conflict do break that
> assumption, unless they are applied globally.
Exclude can already be applied per dependency, it's even the first case of
exclusion supported by Ivy. In this case, the module or set of modules is
excluded only from the transitive set of dependencies resolved for the
direct dependency on which the exclusion is defined, and has no impact on
other dependencies. So if you want to make sure you don't get one module,
you should use global exclude.
BTW, it seems most people like having exclude/override/conflict directly
under dependencies, so I'll go this way, update code and documentation to
support that. Thanks everybody for your feedback.
Xavier
>
> -- Niklas Matthies
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: [LIKELY_SPAM]Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Mon, Mar 31, 2008 at 3:59 PM, Gilles Scokart <gs...@gmail.com> wrote:
> On 31/03/2008, Xavier Hanin <xa...@gmail.com> wrote:
> > On Mon, Mar 31, 2008 at 2:27 PM, Gilles Scokart <gs...@gmail.com>
> wrote:
> >
> > > On 31/03/2008, Niklas Matthies <ml...@nmhq.net> wrote:
> > > > On Mon 2008-03-31 at 08:39h, Johannes Stamminger wrote on ivy-user:
> > > >
> > > > > On Saturday 29 March 2008, Gilles Scokart wrote:
> > > > > > On 28/03/2008, Johannes Stamminger <
> > > Johannes.Stamminger@astrium.eads.net> wrote:
> > > >
> > > > :
> > > > > > > the exclude and override I could imagine that it would make
> > > sense to
> > > > > > > specify them per dependency - not only globally for all
> > > dependencies ...
> > > > > > > ?
> > > > > >
> > > > > > Why would you exclude or overwrite it for one dependency but
> not
> > > for the
> > > > > > others?
> > > >
> > > > :
> > > > > P1 -> L1 -> L2
> > > > > and
> > > > > P1 -> L3 -> L2
> > > > >
> > > > > With the global exclude L2 still is not in P1 though it is
> needed
> > > > > now. With specifying it only for the dependency to L1, people in
> P1
> > > > > get triggered to analyse the dependency again (when detecting
> the
> > > > > newly included L2). With specifying it globally one runs into
> > > > > problems in worst case (dynamic load of L2 in L1) only very
> late.
> > > >
> > > >
> > > > I wonder how the semantics is intended to be anyway (by Ivy).
> > > > What if L1 excludes (some revisions of) L2 because it isn't
> compatible
> > > > with them? Can L3 cause such in incompatible revision to be
> included
> > > > anyway? What if L3 uses <override>?
> > > >
> > > > In that light, it seems to me that applying exclude/override
> globally
> > > > is the only thing that makes sense. The logic by which Ivy prunes
> > > > dependency subtrees is based on the assumption that it doesn't
> matter
> > > > in which order conflicts are considered; that the result will be
> the
> > > > same regardless of the order. Exclude/override/conflict do break
> that
> > > > assumption, unless they are applied globally.
> > > >
> > > >
> > > > -- Niklas Matthies
> > > >
> > >
> > > Ugh. You see it more globally than me.
> > > I was just thinking it is only usefull at a global level, meaning
> > > accros all the dependency of a module.
> > > You pinpoint (rightfully I think) that it only make sense even more
> > > globaly, accross all the modules that may depends on you.
> > > It looks like we will need to manage the conflicts between
> > > exclusion/overwrite/conflict managment ??
> >
> >
> > I don't think it's a problem. The implementation currently works like
> this:
> > override is used to override a dependency descriptor, so that Ivy
> behave
> > *exactly* as if the dependency has been declared with the overriding
> value.
> > exclude works by excluding the dependency from the tree, exactly as if
> the
> > dependency was not declared. As such it beats override.
> > conflict is used only when there is a conflict, after exclude/override
> which
> > are used at metadata level, while conflict management is used at
> resolution
> > level
> >
> > It's still your responsibility when you write a module descriptor to
> perform
> > the required exclude/override/conflict management to make sure you get
> a set
> > of compatible dependencies.
> >
> > This seems fine to me. Do you foresee any problem?
> >
> > Xavier
> >
> >
>
> Well, the use case presented by Niklas is not covered : What if I want
> to exclude a transitive dependency because I'm incompatible with it?
> Maybe I want to tell to my users "hey, never run my code with this
> depdendency!".
>
> Is this scenario realist? I don't know?
I think you can't give that much power to a module. If the caller really
want to use the module with another "incompatible" one, it's up to him.
Maybe he will just load it in a separate classloader, you never know. I
think current system with new mechanism already offers a good deal of
flexibility and control, and we'll later see if we need new mechanisms. But
I think this goes beyond the scope of this discussion and the target for
2.0.0.
Xavier
>
>
> --
> Gilles Scokart
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Niklas Matthies <ml...@nmhq.net>.
On Mon 2008-03-31 at 19:24h, Xavier Hanin wrote on ivy-user:
> On Mon, Mar 31, 2008 at 7:00 PM, Niklas Matthies wrote:
:
> > It's all fine (only) as long you control all the modules involved.
> > But in that case, why wouldn't you simply specify these features
> > globally for your build?
>
> Fine. And specifying globally for the build will somewhat be possible with
> module descriptor inclusion: define a root module descriptor defining your
> excludes, and include this descriptor in all your modules, and you're done.
Maybe I've been too subtle ;). I'm not asking for a new feature here.
The root module descriptor usage is crystal clear to me, and it is
obviously(?) the use case for which the features under discussion are
being introduced/generalized, and yes of course it is covered by them.
No dispute here whatsoever.
What I was trying to get at - while trying not to step on anyone's
toes - is whether these features, as currently envisioned (or already
implemented), aren't actually harmful for the client side (= published
Ivy file), and whether it wouldn't be worth reconsidering how they are
implemented, rather now than later, to avoid having regrets later on
when things can't be changed any more due to having to maintain
backwards compatibility.
As I wrote, it seems to me that having these features in published Ivy
files breaks basic assumptions of Ivy's dependency model (such as the
commutativity and associativity of conflict resolution) and is quite
prone to lead to unintelligible and subtly changing resolution
behavior in non-trivial scenarios.
I was hoping for an exchange of ideas of how these features could be
amended such that the problems mentioned above are avoided, while
still satisfying the actual use cases. Just as an example, one
possible way could be to disallow/not support these features in
non-root modules during dependency resolution. I don't know whether
that would fit the implementation, and wouldn't break any valid use
cases, it's just an example of the kind of approaches I was aiming at.
-- Niklas Matthies
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Mon, Mar 31, 2008 at 7:00 PM, Niklas Matthies <ml...@nmhq.net>
wrote:
> On Mon 2008-03-31 at 18:20h, Xavier Hanin wrote on ivy-user:
> :
> > OTOH, feel free to open an issue in JIRA detailing what you'd like
> > to have (letting a module exclude another one in whole dependency
> > graph).
>
> My feeling is that this is rather about what I *don't* want to have. ;)
> I'm worried about having such modules as dependencies one day, and
> having to work around their published exclude/override/conflict
> directives with yet more such directives in my own modules, and
> possibly having to tell the clients of my own modules to do the same.
>
> It's all fine (only) as long you control all the modules involved.
> But in that case, why wouldn't you simply specify these features
> globally for your build?
Fine. And specifying globally for the build will somewhat be possible with
module descriptor inclusion: define a root module descriptor defining your
excludes, and include this descriptor in all your modules, and you're done.
Xavier
>
>
> -- Niklas Matthies
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Niklas Matthies <ml...@nmhq.net>.
On Mon 2008-03-31 at 18:20h, Xavier Hanin wrote on ivy-user:
:
> OTOH, feel free to open an issue in JIRA detailing what you'd like
> to have (letting a module exclude another one in whole dependency
> graph).
My feeling is that this is rather about what I *don't* want to have. ;)
I'm worried about having such modules as dependencies one day, and
having to work around their published exclude/override/conflict
directives with yet more such directives in my own modules, and
possibly having to tell the clients of my own modules to do the same.
It's all fine (only) as long you control all the modules involved.
But in that case, why wouldn't you simply specify these features
globally for your build?
-- Niklas Matthies
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Mon, Mar 31, 2008 at 5:05 PM, Niklas Matthies <ml...@nmhq.net>
wrote:
> On Mon 2008-03-31 at 15:59h, Gilles Scokart wrote on ivy-user:
> :
> > Well, the use case presented by Niklas is not covered : What if I want
> > to exclude a transitive dependency because I'm incompatible with it?
> > Maybe I want to tell to my users "hey, never run my code with this
> > depdendency!".
> >
> > Is this scenario realist? I don't know?
>
> One important question (I think) is: If someone has published a module
> with a descriptor containing an exclude, what should that tell a
> client using that module? It would be very bad if the client had to
> make sure that none of its other dependencies doesn't include the
> exluded dependency. This would effectively mean that exclude
> directives have to be manually propagated up to the root of the
> dependency tree (and be added to all published descriptors of modules
> along the way). It gets worse when the exclusions evolve over the
> revision history of the excluding module. If, on the other hand, the
> published module is fine with the excluded dependency being imported
> via other modules, then the question is what it really meant by
> excluding the dependency.
>
> There are similar questions for <override> and <conflict>.
> E.g. if I have a module D depending on modules B and C, which both
> transitively depend on a module A, and the descriptor of B specifies
> conflict manager X for A, and module B specifies conflict manager Y
> for A, and my module D uses the default conflict manager to resolve
> conflicts between revisions of A returned by B and C, will B and C be
> happy with the result? And this process is complicated by the fact
> that descriptors are revision-dependent, i.e. it's not really B and C
> that specify conflict managers, it's specific revisions of B and C
> that might specify different conflict managers. Ignoring the complex
> mess that this already creates ;), the <conflict> directives of some
> module B should only be applied after it is known which revision of B
> is ultimately selected, to get consistent results. For example, if you
> have something like (using proper notation ;)):
>
> #D -> {
> #B;1 -> {
> #F;1 -> ... -> #A;1
> #G;1 -> ... -> #A;2
> }
> #H -> ... -> #B;2 -> {
> #F;2 -> ... -> #A;3
> #G;2 -> ... -> #A;4
> }
> }
>
> and #B;2 specifies a different conflict manager for #A than #B;1,
> then if the conflict between #A;1 and #A;2 or between #A;3 and #A;4
> is resolved before the conflict between #B;1 and #B;2 is resolved,
> then the resulting revision of #A may depend on the order on wich the
> direct dependencies of #D (i.e. #B;1 and #H) are traversed. (Note that
> (the author/user of) #D might not even be aware of the fact that #H
> uses #B.) It is my understanding that Ivy intends to define a
> dependency resolution mechanism that is not order-dependent (unlike
> the mess you get with Maven ;)).
You raise some very interesting issues, along with a good understanding of
the complexity behind implementing this kind of feature. IMO, letting a
module give rules for the caller is really a complex feature which requires
a lot of design and testing. I don't think we are ready to go into this kind
of feature yet, so I'd keep the exclude/override/conflict feature as
implemented ATM. OTOH, feel free to open an issue in JIRA detailing what
you'd like to have (letting a module exclude another one in whole dependency
graph).
Xavier
>
>
> -- Niklas Matthies
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Niklas Matthies <ml...@nmhq.net>.
On Mon 2008-03-31 at 15:59h, Gilles Scokart wrote on ivy-user:
:
> Well, the use case presented by Niklas is not covered : What if I want
> to exclude a transitive dependency because I'm incompatible with it?
> Maybe I want to tell to my users "hey, never run my code with this
> depdendency!".
>
> Is this scenario realist? I don't know?
One important question (I think) is: If someone has published a module
with a descriptor containing an exclude, what should that tell a
client using that module? It would be very bad if the client had to
make sure that none of its other dependencies doesn't include the
exluded dependency. This would effectively mean that exclude
directives have to be manually propagated up to the root of the
dependency tree (and be added to all published descriptors of modules
along the way). It gets worse when the exclusions evolve over the
revision history of the excluding module. If, on the other hand, the
published module is fine with the excluded dependency being imported
via other modules, then the question is what it really meant by
excluding the dependency.
There are similar questions for <override> and <conflict>.
E.g. if I have a module D depending on modules B and C, which both
transitively depend on a module A, and the descriptor of B specifies
conflict manager X for A, and module B specifies conflict manager Y
for A, and my module D uses the default conflict manager to resolve
conflicts between revisions of A returned by B and C, will B and C be
happy with the result? And this process is complicated by the fact
that descriptors are revision-dependent, i.e. it's not really B and C
that specify conflict managers, it's specific revisions of B and C
that might specify different conflict managers. Ignoring the complex
mess that this already creates ;), the <conflict> directives of some
module B should only be applied after it is known which revision of B
is ultimately selected, to get consistent results. For example, if you
have something like (using proper notation ;)):
#D -> {
#B;1 -> {
#F;1 -> ... -> #A;1
#G;1 -> ... -> #A;2
}
#H -> ... -> #B;2 -> {
#F;2 -> ... -> #A;3
#G;2 -> ... -> #A;4
}
}
and #B;2 specifies a different conflict manager for #A than #B;1,
then if the conflict between #A;1 and #A;2 or between #A;3 and #A;4
is resolved before the conflict between #B;1 and #B;2 is resolved,
then the resulting revision of #A may depend on the order on wich the
direct dependencies of #D (i.e. #B;1 and #H) are traversed. (Note that
(the author/user of) #D might not even be aware of the fact that #H
uses #B.) It is my understanding that Ivy intends to define a
dependency resolution mechanism that is not order-dependent (unlike
the mess you get with Maven ;)).
-- Niklas Matthies
Re: [LIKELY_SPAM]Re: specify versions separate from dependencies
Posted by Gilles Scokart <gs...@gmail.com>.
On 31/03/2008, Xavier Hanin <xa...@gmail.com> wrote:
> On Mon, Mar 31, 2008 at 2:27 PM, Gilles Scokart <gs...@gmail.com> wrote:
>
> > On 31/03/2008, Niklas Matthies <ml...@nmhq.net> wrote:
> > > On Mon 2008-03-31 at 08:39h, Johannes Stamminger wrote on ivy-user:
> > >
> > > > On Saturday 29 March 2008, Gilles Scokart wrote:
> > > > > On 28/03/2008, Johannes Stamminger <
> > Johannes.Stamminger@astrium.eads.net> wrote:
> > >
> > > :
> > > > > > the exclude and override I could imagine that it would make
> > sense to
> > > > > > specify them per dependency - not only globally for all
> > dependencies ...
> > > > > > ?
> > > > >
> > > > > Why would you exclude or overwrite it for one dependency but not
> > for the
> > > > > others?
> > >
> > > :
> > > > P1 -> L1 -> L2
> > > > and
> > > > P1 -> L3 -> L2
> > > >
> > > > With the global exclude L2 still is not in P1 though it is needed
> > > > now. With specifying it only for the dependency to L1, people in P1
> > > > get triggered to analyse the dependency again (when detecting the
> > > > newly included L2). With specifying it globally one runs into
> > > > problems in worst case (dynamic load of L2 in L1) only very late.
> > >
> > >
> > > I wonder how the semantics is intended to be anyway (by Ivy).
> > > What if L1 excludes (some revisions of) L2 because it isn't compatible
> > > with them? Can L3 cause such in incompatible revision to be included
> > > anyway? What if L3 uses <override>?
> > >
> > > In that light, it seems to me that applying exclude/override globally
> > > is the only thing that makes sense. The logic by which Ivy prunes
> > > dependency subtrees is based on the assumption that it doesn't matter
> > > in which order conflicts are considered; that the result will be the
> > > same regardless of the order. Exclude/override/conflict do break that
> > > assumption, unless they are applied globally.
> > >
> > >
> > > -- Niklas Matthies
> > >
> >
> > Ugh. You see it more globally than me.
> > I was just thinking it is only usefull at a global level, meaning
> > accros all the dependency of a module.
> > You pinpoint (rightfully I think) that it only make sense even more
> > globaly, accross all the modules that may depends on you.
> > It looks like we will need to manage the conflicts between
> > exclusion/overwrite/conflict managment ??
>
>
> I don't think it's a problem. The implementation currently works like this:
> override is used to override a dependency descriptor, so that Ivy behave
> *exactly* as if the dependency has been declared with the overriding value.
> exclude works by excluding the dependency from the tree, exactly as if the
> dependency was not declared. As such it beats override.
> conflict is used only when there is a conflict, after exclude/override which
> are used at metadata level, while conflict management is used at resolution
> level
>
> It's still your responsibility when you write a module descriptor to perform
> the required exclude/override/conflict management to make sure you get a set
> of compatible dependencies.
>
> This seems fine to me. Do you foresee any problem?
>
> Xavier
>
>
Well, the use case presented by Niklas is not covered : What if I want
to exclude a transitive dependency because I'm incompatible with it?
Maybe I want to tell to my users "hey, never run my code with this
depdendency!".
Is this scenario realist? I don't know?
--
Gilles Scokart
Re: [LIKELY_SPAM]Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Mon, Mar 31, 2008 at 2:27 PM, Gilles Scokart <gs...@gmail.com> wrote:
> On 31/03/2008, Niklas Matthies <ml...@nmhq.net> wrote:
> > On Mon 2008-03-31 at 08:39h, Johannes Stamminger wrote on ivy-user:
> >
> > > On Saturday 29 March 2008, Gilles Scokart wrote:
> > > > On 28/03/2008, Johannes Stamminger <
> Johannes.Stamminger@astrium.eads.net> wrote:
> >
> > :
> > > > > the exclude and override I could imagine that it would make
> sense to
> > > > > specify them per dependency - not only globally for all
> dependencies ...
> > > > > ?
> > > >
> > > > Why would you exclude or overwrite it for one dependency but not
> for the
> > > > others?
> >
> > :
> > > P1 -> L1 -> L2
> > > and
> > > P1 -> L3 -> L2
> > >
> > > With the global exclude L2 still is not in P1 though it is needed
> > > now. With specifying it only for the dependency to L1, people in P1
> > > get triggered to analyse the dependency again (when detecting the
> > > newly included L2). With specifying it globally one runs into
> > > problems in worst case (dynamic load of L2 in L1) only very late.
> >
> >
> > I wonder how the semantics is intended to be anyway (by Ivy).
> > What if L1 excludes (some revisions of) L2 because it isn't compatible
> > with them? Can L3 cause such in incompatible revision to be included
> > anyway? What if L3 uses <override>?
> >
> > In that light, it seems to me that applying exclude/override globally
> > is the only thing that makes sense. The logic by which Ivy prunes
> > dependency subtrees is based on the assumption that it doesn't matter
> > in which order conflicts are considered; that the result will be the
> > same regardless of the order. Exclude/override/conflict do break that
> > assumption, unless they are applied globally.
> >
> >
> > -- Niklas Matthies
> >
>
> Ugh. You see it more globally than me.
> I was just thinking it is only usefull at a global level, meaning
> accros all the dependency of a module.
> You pinpoint (rightfully I think) that it only make sense even more
> globaly, accross all the modules that may depends on you.
> It looks like we will need to manage the conflicts between
> exclusion/overwrite/conflict managment ??
I don't think it's a problem. The implementation currently works like this:
override is used to override a dependency descriptor, so that Ivy behave
*exactly* as if the dependency has been declared with the overriding value.
exclude works by excluding the dependency from the tree, exactly as if the
dependency was not declared. As such it beats override.
conflict is used only when there is a conflict, after exclude/override which
are used at metadata level, while conflict management is used at resolution
level
It's still your responsibility when you write a module descriptor to perform
the required exclude/override/conflict management to make sure you get a set
of compatible dependencies.
This seems fine to me. Do you foresee any problem?
Xavier
>
>
>
>
>
> --
> Gilles Scokart
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: [LIKELY_SPAM]Re: specify versions separate from dependencies
Posted by Gilles Scokart <gs...@gmail.com>.
On 31/03/2008, Niklas Matthies <ml...@nmhq.net> wrote:
> On Mon 2008-03-31 at 08:39h, Johannes Stamminger wrote on ivy-user:
>
> > On Saturday 29 March 2008, Gilles Scokart wrote:
> > > On 28/03/2008, Johannes Stamminger <Jo...@astrium.eads.net> wrote:
>
> :
> > > > the exclude and override I could imagine that it would make sense to
> > > > specify them per dependency - not only globally for all dependencies ...
> > > > ?
> > >
> > > Why would you exclude or overwrite it for one dependency but not for the
> > > others?
>
> :
> > P1 -> L1 -> L2
> > and
> > P1 -> L3 -> L2
> >
> > With the global exclude L2 still is not in P1 though it is needed
> > now. With specifying it only for the dependency to L1, people in P1
> > get triggered to analyse the dependency again (when detecting the
> > newly included L2). With specifying it globally one runs into
> > problems in worst case (dynamic load of L2 in L1) only very late.
>
>
> I wonder how the semantics is intended to be anyway (by Ivy).
> What if L1 excludes (some revisions of) L2 because it isn't compatible
> with them? Can L3 cause such in incompatible revision to be included
> anyway? What if L3 uses <override>?
>
> In that light, it seems to me that applying exclude/override globally
> is the only thing that makes sense. The logic by which Ivy prunes
> dependency subtrees is based on the assumption that it doesn't matter
> in which order conflicts are considered; that the result will be the
> same regardless of the order. Exclude/override/conflict do break that
> assumption, unless they are applied globally.
>
>
> -- Niklas Matthies
>
Ugh. You see it more globally than me.
I was just thinking it is only usefull at a global level, meaning
accros all the dependency of a module.
You pinpoint (rightfully I think) that it only make sense even more
globaly, accross all the modules that may depends on you.
It looks like we will need to manage the conflicts between
exclusion/overwrite/conflict managment ??
--
Gilles Scokart
Re: [LIKELY_SPAM]Re: specify versions separate from dependencies
Posted by Niklas Matthies <ml...@nmhq.net>.
On Mon 2008-03-31 at 08:39h, Johannes Stamminger wrote on ivy-user:
> On Saturday 29 March 2008, Gilles Scokart wrote:
> > On 28/03/2008, Johannes Stamminger <Jo...@astrium.eads.net> wrote:
:
> > > the exclude and override I could imagine that it would make sense to
> > > specify them per dependency - not only globally for all dependencies ...
> > > ?
> >
> > Why would you exclude or overwrite it for one dependency but not for the
> > others?
:
> P1 -> L1 -> L2
> and
> P1 -> L3 -> L2
>
> With the global exclude L2 still is not in P1 though it is needed
> now. With specifying it only for the dependency to L1, people in P1
> get triggered to analyse the dependency again (when detecting the
> newly included L2). With specifying it globally one runs into
> problems in worst case (dynamic load of L2 in L1) only very late.
I wonder how the semantics is intended to be anyway (by Ivy).
What if L1 excludes (some revisions of) L2 because it isn't compatible
with them? Can L3 cause such in incompatible revision to be included
anyway? What if L3 uses <override>?
In that light, it seems to me that applying exclude/override globally
is the only thing that makes sense. The logic by which Ivy prunes
dependency subtrees is based on the assumption that it doesn't matter
in which order conflicts are considered; that the result will be the
same regardless of the order. Exclude/override/conflict do break that
assumption, unless they are applied globally.
-- Niklas Matthies
Re: [LIKELY_SPAM]Re: specify versions separate from dependencies
Posted by Johannes Stamminger <Jo...@astrium.eads.net>.
On Saturday 29 March 2008, Gilles Scokart wrote:
> On 28/03/2008, Johannes Stamminger <Jo...@astrium.eads.net>
wrote:
> > just my 2 cents (maybe I am completely wrong as I did not follow the
> > discussion in all detail and the tread is rather long ... and it is
> > friday eventing here :-)):
> >
> > the exclude and override I could imagine that it would make sense to
> > specify them per dependency - not only globally for all dependencies ...
> > ?
>
> Why would you exclude or overwrite it for one dependency but not for the
> others?
Due to a possible change of dependent libs:
E.g. for exclusion: when first setting up dependencies one might have
P1 -> L1 -> L2
and
P1 -> L3
And now per analysis it is decided that in P1 nothing of L1 is reffed that
needs L2.
Now L3 changes and one has:
P1 -> L1 -> L2
and
P1 -> L3 -> L2
With the global exclude L2 still is not in P1 though it is needed now. With
specifying it only for the dependency to L1, people in P1 get triggered to
analyse the dependency again (when detecting the newly included L2). With
specifying it globally one runs into problems in worst case (dynamic load of
L2 in L1) only very late.
>
> Concerning the idea to put the new tags directly under dependencies, I like
> it.
Me too.
Johannes Stamminger
--
Johannes.Stamminger@Astrium.EADS.net [2FE783D0 http://wwwkeys.PGP.net]
------ ----<--{(@ ------------------ EADS ASTRIUM
Koenigsberger Str. 17, 28857 Barrien Ground System Eng. (TE55)
+49 4242 169582 (Tel + FAX) Airbus Allee 1, 28199 Bremen
+49 174 7731593 (Mobile) +49 421 539 4152 (Tel) / 4378 (FAX)
This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Astrium disclaims any and all liability if this email transmission was virus corrupted, altered or falsified.
---------------------------------------------------------
Astrium GmbH Vorsitzender des Aufsichtsrates: Thomas Mueller - Geschaeftsfuehrung: Evert Dudok (Vorsitzender), Dr. Reinhold Lutz, Pablo Salame Fischer, Guenter Stamerjohanns
Sitz der Gesellschaft: Muenchen - Registergericht: Amtsgericht Muenchen, HRB Nr. 107 647
Weitere Informationen ueber EADS Astrium @ http://www.astrium.eads.net/
Re: [LIKELY_SPAM]Re: specify versions separate from dependencies
Posted by Gilles Scokart <gs...@gmail.com>.
On 28/03/2008, Johannes Stamminger <Jo...@astrium.eads.net> wrote:
>
> just my 2 cents (maybe I am completely wrong as I did not follow the
> discussion in all detail and the tread is rather long ... and it is friday
> eventing here :-)):
>
> the exclude and override I could imagine that it would make sense to specify
> them per dependency - not only globally for all dependencies ... ?
>
>
Why would you exclude or overwrite it for one dependency but not for the others?
Concerning the idea to put the new tags directly under dependencies, I like it.
--
Gilles Scokart
Re: [LIKELY_SPAM]Re: specify versions separate from dependencies
Posted by Johannes Stamminger <Jo...@astrium.eads.net>.
just my 2 cents (maybe I am completely wrong as I did not follow the
discussion in all detail and the tread is rather long ... and it is friday
eventing here :-)):
the exclude and override I could imagine that it would make sense to specify
them per dependency - not only globally for all dependencies ... ?
On Friday 28 March 2008, Xavier Hanin wrote:
> On Fri, Mar 28, 2008 at 6:38 PM, Niklas Matthies <ml...@nmhq.net>
>
> wrote:
> > On Fri 2008-03-28 at 17:24h, Xavier Hanin wrote on ivy-user:
> > > FYI, I've just checked in code which uses the proposed syntax. Here's
> > > an extract of an ivy file used in ivy file parsing test:
> > > <dependencies>
> > > [...]
> > > <dependency org="yourorg" name="yourmodule11" rev="11.1"
> >
> > conf="*->@"/>
> >
> > > <hints>
> > > <exclude module="*servlet*" matcher="glob" conf="myconf1"
> > > /> <exclude org="acme" module="test" artifact="test"
> >
> > type="source" ext="jar" />
> >
> > > <conflict org="yourorg" module=".*" matcher="regexp"
> >
> > manager="all" />
> >
> > > <conflict org="theirorg" module="theirmodule1" rev="1.0,
> > > 1.1
> >
> > "/>
> >
> > > <override org="yourorg" module=".*1" matcher="regexp"
> >
> > branch="BRANCH" rev="1.0" />
> >
> > > </hints>
> > > </dependencies>
> > >
> > > This is still open to discussion, if you have better ideas for the
> >
> > syntax,
> >
> > > or a better name than 'hints', please give feedback before we cut next
> > > release.
> >
> > How about just placing these elements directly under <dependencies>?
> > This would read pretty natural to me.
>
> It would at least avoid to find a better word than "hints" :-) I'm fine
> with putting them directly under dependencies. What do others think?
>
> Xavier
>
> > -- Niklas Matthies
--
Johannes.Stamminger@Astrium.EADS.net [2FE783D0 http://wwwkeys.PGP.net]
------ ----<--{(@ ------------------ EADS ASTRIUM
Koenigsberger Str. 17, 28857 Barrien Ground System Eng. (TE55)
+49 4242 169582 (Tel + FAX) Airbus Allee 1, 28199 Bremen
+49 174 7731593 (Mobile) +49 421 539 4152 (Tel) / 4378 (FAX)
This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Astrium disclaims any and all liability if this email transmission was virus corrupted, altered or falsified.
---------------------------------------------------------
Astrium GmbH Vorsitzender des Aufsichtsrates: Thomas Mueller - Geschaeftsfuehrung: Evert Dudok (Vorsitzender), Dr. Reinhold Lutz, Pablo Salame Fischer, Guenter Stamerjohanns
Sitz der Gesellschaft: Muenchen - Registergericht: Amtsgericht Muenchen, HRB Nr. 107 647
Weitere Informationen ueber EADS Astrium @ http://www.astrium.eads.net/
RE: specify versions separate from dependencies
Posted by "Brown, Carlton" <Ca...@compucredit.com>.
> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: Friday, March 28, 2008 1:43 PM
> To: ivy-user@ant.apache.org
> Subject: Re: specify versions separate from dependencies
>
> On Fri, Mar 28, 2008 at 6:38 PM, Niklas Matthies
> <ml...@nmhq.net>
> wrote:
>
> > How about just placing these elements directly under <dependencies>?
> > This would read pretty natural to me.
>
> It would at least avoid to find a better word than "hints"
> :-) I'm fine with putting them directly under dependencies.
> What do others think?
I agree that it seems most natural to place them directly under
<dependencies>.
-----------------------------------------
====================================================
This message contains PRIVILEGED and CONFIDENTIAL
information that is intended only for use by the
named recipient. If you are not the named recipient,
any disclosure, dissemination, or action based on
the contents of this message is prohibited. In such
case please notify us and destroy and delete all
copies of this transmission. Thank you.
====================================================
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Fri, Mar 28, 2008 at 6:38 PM, Niklas Matthies <ml...@nmhq.net>
wrote:
> On Fri 2008-03-28 at 17:24h, Xavier Hanin wrote on ivy-user:
> > FYI, I've just checked in code which uses the proposed syntax. Here's an
> > extract of an ivy file used in ivy file parsing test:
> > <dependencies>
> > [...]
> > <dependency org="yourorg" name="yourmodule11" rev="11.1"
> conf="*->@"/>
> >
> > <hints>
> > <exclude module="*servlet*" matcher="glob" conf="myconf1" />
> > <exclude org="acme" module="test" artifact="test"
> type="source" ext="jar" />
> > <conflict org="yourorg" module=".*" matcher="regexp"
> manager="all" />
> > <conflict org="theirorg" module="theirmodule1" rev="1.0, 1.1
> "/>
> > <override org="yourorg" module=".*1" matcher="regexp"
> branch="BRANCH" rev="1.0" />
> > </hints>
> > </dependencies>
> :
> > This is still open to discussion, if you have better ideas for the
> syntax,
> > or a better name than 'hints', please give feedback before we cut next
> > release.
>
> How about just placing these elements directly under <dependencies>?
> This would read pretty natural to me.
It would at least avoid to find a better word than "hints" :-) I'm fine with
putting them directly under dependencies. What do others think?
Xavier
>
>
> -- Niklas Matthies
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Niklas Matthies <ml...@nmhq.net>.
On Fri 2008-03-28 at 17:24h, Xavier Hanin wrote on ivy-user:
> FYI, I've just checked in code which uses the proposed syntax. Here's an
> extract of an ivy file used in ivy file parsing test:
> <dependencies>
> [...]
> <dependency org="yourorg" name="yourmodule11" rev="11.1" conf="*->@"/>
>
> <hints>
> <exclude module="*servlet*" matcher="glob" conf="myconf1" />
> <exclude org="acme" module="test" artifact="test" type="source" ext="jar" />
> <conflict org="yourorg" module=".*" matcher="regexp" manager="all" />
> <conflict org="theirorg" module="theirmodule1" rev="1.0, 1.1"/>
> <override org="yourorg" module=".*1" matcher="regexp" branch="BRANCH" rev="1.0" />
> </hints>
> </dependencies>
:
> This is still open to discussion, if you have better ideas for the syntax,
> or a better name than 'hints', please give feedback before we cut next
> release.
How about just placing these elements directly under <dependencies>?
This would read pretty natural to me.
-- Niklas Matthies
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
FYI, I've just checked in code which uses the proposed syntax. Here's an
extract of an ivy file used in ivy file parsing test:
<dependencies>
[...]
<dependency org="yourorg" name="yourmodule11" rev="11.1"
conf="*->@"/>
<hints>
<exclude module="*servlet*" matcher="glob" conf="myconf1" />
<exclude org="acme" module="test" artifact="test" type="source"
ext="jar" />
<conflict org="yourorg" module=".*" matcher="regexp"
manager="all" />
<conflict org="theirorg" module="theirmodule1" rev="1.0, 1.1"/>
<override org="yourorg" module=".*1" matcher="regexp"
branch="BRANCH" rev="1.0" />
</hints>
</dependencies>
I find this pretty readable. I've also deprecated the use of conflicts
section (if descriptor version is > 1.4), and global exclude directly under
dependencies.
I still need to update the doc, and implement overrides writing to support
pom to ivy file conversion when dependency management is used and resolve
IVY-753.
This is still open to discussion, if you have better ideas for the syntax,
or a better name than 'hints', please give feedback before we cut next
release.
Xavier
Re: specify versions separate from dependencies
Posted by Niklas Matthies <ml...@nmhq.net>.
On Fri 2008-03-28 at 09:10h, Xavier Hanin wrote on ivy-user:
> On Fri, Mar 28, 2008 at 9:03 AM, Gilles Scokart <gs...@gmail.com> wrote:
>
> > I like the hints syntax under dependencies. (Even I'm not sure hints
> > is the right word).
>
> Maybe an english speaker could help clarify this?
I'm not an english speaker, but the term "hint" in programming
contexts usually means some piece of information that helps to
optimize a process/algorithm, but doesn't change its semantics.
For example hints in SQL queries, which may improve the execution
plan of a query, but don't change its result. Or with a lookup
algorithms, it may be possible to specify a key/index as a hint where
to start the search, so that the algorithm might find the target
faster. But it only impacts the execution time of the algorithm, the
actual result will be exactly the same regardless of what was
specified as a hint. Another example is hints on branch instructions
on modern CPUs, which tell the CPU whether the instruction is more
likely to branch or not, so that the CPU can speculatively execute the
instructions that follow until the branch condition has finished
evaluating. If the hint turns out to be wrong, the program merely
runs slower. Sometimes a "hint" does influence the actual result, but
only insofar as a different correct result is picked from a set of
several correct results. "Font hinting" is an example of that.
Therefore I wouldn't use the word "hint" here with Ivy.
-- Niklas Matthies
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Fri, Mar 28, 2008 at 9:03 AM, Gilles Scokart <gs...@gmail.com> wrote:
> I like the hints syntax under dependencies. (Even I'm not sure hints
> is the right word).
Maybe an english speaker could help clarify this?
> I agree with Jim. We must have the possibility to centraly manage
> your 'hints'. Typically in a multi-module product, the 'hints' will
> be a global charachteristic of the product, and only occasionaly
> something specific to a module.
>
> So, I think that allowing to include a file like we can include a file
> for the configurations would be a good solution. Like Xavier, I'm not
> in favor of adding this to the settings.
>
> However, when published, the included files must be in-lined so that
> the published files are self-containing.
Agreed. I think we already have an open issue for the support of file
inclusion.
>
>
> Finally, I'm currious to see how the new feature will impact the build
> traces and the dependency report.
ATM dependency overriding is only traced in verbose mode. All other traces
and report are displayed as if the dependency was declared with the
overriding value. I'll try to see if I can improve that.
Xavier
>
>
> Gilles
>
>
> On 24/03/2008, Jim Adams <Ji...@sas.com> wrote:
> > Is there any way to include this from another file? What I am thinking
> of is that we have a properties file filled with the default versions of
> third party dependencies that our build wants to use. We have different
> build tracks, corresponding to different installable portions of our system,
> where people may decide that they want to override the original third party
> dependencies. It seems that this would be possible with this system. I am
> concerned that I will end up with conflicts, however, and not know it nor
> really understand the implications of these conflicts.
> >
> >
> > > -----Original Message-----
> > > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> >
> > > Sent: Monday, March 24, 2008 2:31 PM
> > > To: ivy-user@ant.apache.org
> > > Subject: Re: specify versions separate from dependencies
> > >
> >
> > > I've started working on this, and come close to a solution. To
> finalize my
> > > work, we need to decide upon the syntax we want to use in Ivy files
> to
> > > support transitive dependency override mechanism.
> > >
> > > After some more thoughts on the feature and how it relates to
> existing Ivy
> > > features, I think we now have 3 different ways to influence
> transitive
> > > dependencies in an Ivy file:
> > > - transitive dependency exclusion (IVY-431), introduced in
> 2.0.0-alpha1.
> > > This feature relies on an 'exclude' tag directly under the
> 'dependencies'
> > > element.
> > > - setting specific conflict managers for transitive dependencies.
> This
> > > relies on a 'conflicts' element and its child elements 'manager'.
> > > - overriding version and/or branch of transitive dependencies. In the
> > > implementation, I've opened the door to more feature than that, by
> > > implementing a dependency descriptor mediator mechanism. Whenever we
> load a
> > > module descriptor dependency descriptors to resolve them, we first
> ask all
> > > the dependers to mediate each dependency descriptor. Then we use the
> > > mediated dependency descriptor to resolve the dependency, instead of
> the
> > > original one. For the moment I've only implemented one mediator,
> called
> > > override. But we could later imagine other kinds of mediation which
> happens
> > > before actual dependency resolution. For the moment I've used this
> syntax
> > > for this new feature:
> > > <engine-hints>
> > > <mediation>
> > > <override org="yourorg" module=".*1" matcher="regexp"
> > > branch="BRANCH" rev="1.0" />
> > > </mediation>
> > > </engine-hints>
> > > This section is put directly under ivy-module element. What I would
> like to
> > > do is group the three kind of transitive dependencies hints we can
> give to
> > > the resolve engine in an ivy file. I'm still wondering what is the
> best
> > > syntax, and if we can afford deprecating the syntax of conflicts and
> module
> > > wide exclude. If we agree to deprecate them, here's one idea for the
> new
> > > syntax:
> > > <ivy-module>
> > > <dependencies>
> > > <dependency ... />
> > > <dependency ... />
> > > ...
> > > <hints>
> > > <exclude org="" module="" matcher="" ... />
> > > <conflict org="" module="" matcher="" rev|manager="" />
> > > <override org="" module="" matcher="" branch="" rev="" />
> > > </hints>
> > > </dependencies>
> > > </ivy-module>
> > > The conflict tag is similar to the current conflicts/manager tag,
> except
> > > that the 'name' attribute is replaced by 'manager'.
> > > All three kind of hints share the same attribute triple (org - module
> -
> > > matcher). The usage of this uple is slightly different in exclude,
> where it
> > > also applied to other attributes, such as artifact (to name the
> artifacts to
> > > exclude transitively).
> > >
> > > Another approach would be to put the hints section directly under
> ivy-module
> > > instead of under dependencies (as it's the case for conflicts/manager
> > > today). I think I prefer the former approach I propose.
> > >
> > > This is open to discussion, please give your feedback, once 2.0 will
> be out
> > > we won't be able to go back.
> > >
> > > Xavier
> > >
> > > On Wed, Feb 27, 2008 at 8:30 PM, Harald Braumann <ha...@unheit.net>
> wrote:
> > >
> > > > On Wed, 27 Feb 2008 14:23:50 +0100
> > > > "Xavier Hanin" <xa...@gmail.com> wrote:
> > > >
> > > > > Could you open an issue about that?
> > > >
> > > > Here it is: https://issues.apache.org/jira/browse/IVY-753
> > > >
> > > > harry
> > > >
> > >
> > >
> > >
> > > --
> > > Xavier Hanin - Independent Java Consultant
> > > http://xhab.blogspot.com/
> > > http://ant.apache.org/ivy/
> > > http://www.xoocode.org/
> >
>
>
> --
> Gilles Scokart
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Gilles Scokart <gs...@gmail.com>.
I like the hints syntax under dependencies. (Even I'm not sure hints
is the right word).
I agree with Jim. We must have the possibility to centraly manage
your 'hints'. Typically in a multi-module product, the 'hints' will
be a global charachteristic of the product, and only occasionaly
something specific to a module.
So, I think that allowing to include a file like we can include a file
for the configurations would be a good solution. Like Xavier, I'm not
in favor of adding this to the settings.
However, when published, the included files must be in-lined so that
the published files are self-containing.
Finally, I'm currious to see how the new feature will impact the build
traces and the dependency report.
Gilles
On 24/03/2008, Jim Adams <Ji...@sas.com> wrote:
> Is there any way to include this from another file? What I am thinking of is that we have a properties file filled with the default versions of third party dependencies that our build wants to use. We have different build tracks, corresponding to different installable portions of our system, where people may decide that they want to override the original third party dependencies. It seems that this would be possible with this system. I am concerned that I will end up with conflicts, however, and not know it nor really understand the implications of these conflicts.
>
>
> > -----Original Message-----
> > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
>
> > Sent: Monday, March 24, 2008 2:31 PM
> > To: ivy-user@ant.apache.org
> > Subject: Re: specify versions separate from dependencies
> >
>
> > I've started working on this, and come close to a solution. To finalize my
> > work, we need to decide upon the syntax we want to use in Ivy files to
> > support transitive dependency override mechanism.
> >
> > After some more thoughts on the feature and how it relates to existing Ivy
> > features, I think we now have 3 different ways to influence transitive
> > dependencies in an Ivy file:
> > - transitive dependency exclusion (IVY-431), introduced in 2.0.0-alpha1.
> > This feature relies on an 'exclude' tag directly under the 'dependencies'
> > element.
> > - setting specific conflict managers for transitive dependencies. This
> > relies on a 'conflicts' element and its child elements 'manager'.
> > - overriding version and/or branch of transitive dependencies. In the
> > implementation, I've opened the door to more feature than that, by
> > implementing a dependency descriptor mediator mechanism. Whenever we load a
> > module descriptor dependency descriptors to resolve them, we first ask all
> > the dependers to mediate each dependency descriptor. Then we use the
> > mediated dependency descriptor to resolve the dependency, instead of the
> > original one. For the moment I've only implemented one mediator, called
> > override. But we could later imagine other kinds of mediation which happens
> > before actual dependency resolution. For the moment I've used this syntax
> > for this new feature:
> > <engine-hints>
> > <mediation>
> > <override org="yourorg" module=".*1" matcher="regexp"
> > branch="BRANCH" rev="1.0" />
> > </mediation>
> > </engine-hints>
> > This section is put directly under ivy-module element. What I would like to
> > do is group the three kind of transitive dependencies hints we can give to
> > the resolve engine in an ivy file. I'm still wondering what is the best
> > syntax, and if we can afford deprecating the syntax of conflicts and module
> > wide exclude. If we agree to deprecate them, here's one idea for the new
> > syntax:
> > <ivy-module>
> > <dependencies>
> > <dependency ... />
> > <dependency ... />
> > ...
> > <hints>
> > <exclude org="" module="" matcher="" ... />
> > <conflict org="" module="" matcher="" rev|manager="" />
> > <override org="" module="" matcher="" branch="" rev="" />
> > </hints>
> > </dependencies>
> > </ivy-module>
> > The conflict tag is similar to the current conflicts/manager tag, except
> > that the 'name' attribute is replaced by 'manager'.
> > All three kind of hints share the same attribute triple (org - module -
> > matcher). The usage of this uple is slightly different in exclude, where it
> > also applied to other attributes, such as artifact (to name the artifacts to
> > exclude transitively).
> >
> > Another approach would be to put the hints section directly under ivy-module
> > instead of under dependencies (as it's the case for conflicts/manager
> > today). I think I prefer the former approach I propose.
> >
> > This is open to discussion, please give your feedback, once 2.0 will be out
> > we won't be able to go back.
> >
> > Xavier
> >
> > On Wed, Feb 27, 2008 at 8:30 PM, Harald Braumann <ha...@unheit.net> wrote:
> >
> > > On Wed, 27 Feb 2008 14:23:50 +0100
> > > "Xavier Hanin" <xa...@gmail.com> wrote:
> > >
> > > > Could you open an issue about that?
> > >
> > > Here it is: https://issues.apache.org/jira/browse/IVY-753
> > >
> > > harry
> > >
> >
> >
> >
> > --
> > Xavier Hanin - Independent Java Consultant
> > http://xhab.blogspot.com/
> > http://ant.apache.org/ivy/
> > http://www.xoocode.org/
>
--
Gilles Scokart
Re: specify versions separate from dependencies
Posted by Harald Braumann <ha...@unheit.net>.
On Mon, 24 Mar 2008 15:55:17 -0400
Jim Adams <Ji...@sas.com> wrote:
> I can't think of any way to set a global default version other than
> properties.
Well, an ivy file, which has the added advantage that it also can be
published to be used by others.
> This was Xavier's suggestion and it has worked out well.
> But here we are talking about overriding a decision made by a
> dependent jar. I need foo version 2 and bar while bar requires foo
> version 1. This is clearly a conflict but somewhere foo says that
> life is ok and we can live with this inconsistency. The problem comes
> when baz has been including foo and bar for quite some time and
> suddenly needs my jar. What did I just do to him silently?
I don't understand the problem here. You always get this sort of
conflicts with transitive dependencies. But with overrides you now get
the chance to fix them.
harry
>
> > -----Original Message-----
> > From: Harald Braumann [mailto:harry@unheit.net]
> > Sent: Monday, March 24, 2008 3:43 PM
> > To: ivy-user@ant.apache.org
> > Subject: Re: specify versions separate from dependencies
> >
> > On Mon, 24 Mar 2008 14:48:11 -0400
> > Jim Adams <Ji...@sas.com> wrote:
> >
> > > Is there any way to include this from another file? What I am
> > > thinking of is that we have a properties file filled with the
> > > default versions of third party dependencies that our build wants
> > > to use. We have different build tracks, corresponding to
> > > different installable portions of our system, where people may
> > > decide that they want to override the original third party
> > > dependencies.
> > I think property files are not flexible enough. There already was
> > the discussion about some kind of parent file where you can specify
> > your overrides. This could be included in the ivy file.
> >
> > > It seems that this
> > > would be possible with this system. I am concerned that I will
> > > end up with conflicts, however, and not know it nor really
> > > understand the implications of these conflicts.
> > I don't see much difference to "normal" conflicts. If A depends on
> > B and C and both, B and C have overrides on D, than from the point
> > of view of A there are two possible versions for D which would have
> > to be resolved. Just the same as when there where two conflicting
> > normal transitive dependencies on D. With the override mechanism
> > you can now choose the version of D in A's ivy file or in its
> > parent, if that feature will be implemented.
> >
> > harry
> >
> > >
> > > > -----Original Message-----
> > > > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > > > Sent: Monday, March 24, 2008 2:31 PM
> > > > To: ivy-user@ant.apache.org
> > > > Subject: Re: specify versions separate from dependencies
> > > >
> > > > I've started working on this, and come close to a solution. To
> > > > finalize my work, we need to decide upon the syntax we want to
> > > > use in Ivy files to support transitive dependency override
> > > > mechanism.
> > > >
> > > > After some more thoughts on the feature and how it relates to
> > > > existing Ivy features, I think we now have 3 different ways to
> > > > influence transitive dependencies in an Ivy file:
> > > > - transitive dependency exclusion (IVY-431), introduced in
> > > > 2.0.0-alpha1. This feature relies on an 'exclude' tag directly
> > > > under the 'dependencies' element.
> > > > - setting specific conflict managers for transitive
> > > > dependencies. This relies on a 'conflicts' element and its
> > > > child elements 'manager'.
> > > > - overriding version and/or branch of transitive dependencies.
> > > > In the implementation, I've opened the door to more feature
> > > > than that, by implementing a dependency descriptor mediator
> > > > mechanism. Whenever we load a module descriptor dependency
> > > > descriptors to resolve them, we first ask all the dependers to
> > > > mediate each dependency descriptor. Then we use the mediated
> > > > dependency descriptor to resolve the dependency, instead of the
> > > > original one. For the moment I've only implemented one
> > > > mediator, called override. But we could later imagine other
> > > > kinds of mediation which happens before actual dependency
> > > > resolution. For the moment I've used this syntax for this new
> > > > feature: <engine-hints> <mediation>
> > > > <override org="yourorg" module=".*1"
> > > > matcher="regexp" branch="BRANCH" rev="1.0" />
> > > > </mediation>
> > > > </engine-hints>
> > > > This section is put directly under ivy-module element. What I
> > > > would like to do is group the three kind of transitive
> > > > dependencies hints we can give to the resolve engine in an ivy
> > > > file. I'm still wondering what is the best syntax, and if we
> > > > can afford deprecating the syntax of conflicts and module wide
> > > > exclude. If we agree to deprecate them, here's one idea for the
> > > > new syntax: <ivy-module>
> > > > <dependencies>
> > > > <dependency ... />
> > > > <dependency ... />
> > > > ...
> > > > <hints>
> > > > <exclude org="" module="" matcher="" ... />
> > > > <conflict org="" module="" matcher="" rev|manager="" />
> > > > <override org="" module="" matcher="" branch="" rev="" />
> > > > </hints>
> > > > </dependencies>
> > > > </ivy-module>
> > > > The conflict tag is similar to the current conflicts/manager
> > > > tag, except that the 'name' attribute is replaced by 'manager'.
> > > > All three kind of hints share the same attribute triple (org -
> > > > module - matcher). The usage of this uple is slightly different
> > > > in exclude, where it also applied to other attributes, such as
> > > > artifact (to name the artifacts to exclude transitively).
> > > >
> > > > Another approach would be to put the hints section directly
> > > > under ivy-module instead of under dependencies (as it's the
> > > > case for conflicts/manager today). I think I prefer the former
> > > > approach I propose.
> > > >
> > > > This is open to discussion, please give your feedback, once 2.0
> > > > will be out we won't be able to go back.
> > > >
> > > > Xavier
> > > >
> > > > On Wed, Feb 27, 2008 at 8:30 PM, Harald Braumann
> > > > <ha...@unheit.net> wrote:
> > > >
> > > > > On Wed, 27 Feb 2008 14:23:50 +0100 "Xavier Hanin"
> > > > > <xa...@gmail.com> wrote:
> > > > >
> > > > > > Could you open an issue about that?
> > > > >
> > > > > Here it is: https://issues.apache.org/jira/browse/IVY-753
> > > > >
> > > > > harry
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Xavier Hanin - Independent Java Consultant
> > > > http://xhab.blogspot.com/ http://ant.apache.org/ivy/
> > > > http://www.xoocode.org/
RE: specify versions separate from dependencies
Posted by Jim Adams <Ji...@sas.com>.
I can't think of any way to set a global default version other than properties. This was Xavier's suggestion and it has worked out well. But here we are talking about overriding a decision made by a dependent jar. I need foo version 2 and bar while bar requires foo version 1. This is clearly a conflict but somewhere foo says that life is ok and we can live with this inconsistency. The problem comes when baz has been including foo and bar for quite some time and suddenly needs my jar. What did I just do to him silently?
> -----Original Message-----
> From: Harald Braumann [mailto:harry@unheit.net]
> Sent: Monday, March 24, 2008 3:43 PM
> To: ivy-user@ant.apache.org
> Subject: Re: specify versions separate from dependencies
>
> On Mon, 24 Mar 2008 14:48:11 -0400
> Jim Adams <Ji...@sas.com> wrote:
>
> > Is there any way to include this from another file? What I am thinking
> > of is that we have a properties file filled with the default versions
> > of third party dependencies that our build wants to use. We have
> > different build tracks, corresponding to different installable
> > portions of our system, where people may decide that they want to
> > override the original third party dependencies.
> I think property files are not flexible enough. There already was the discussion about some kind of parent file
> where you can specify your overrides. This could be included in the ivy file.
>
> > It seems that this
> > would be possible with this system. I am concerned that I will end up
> > with conflicts, however, and not know it nor really understand the
> > implications of these conflicts.
> I don't see much difference to "normal" conflicts. If A depends on B and C and both, B and C have overrides on
> D, than from the point of view of A there are two possible versions for D which would have to be resolved. Just
> the same as when there where two conflicting normal transitive dependencies on D. With the override mechanism
> you can now choose the version of D in A's ivy file or in its parent, if that feature will be implemented.
>
> harry
>
> >
> > > -----Original Message-----
> > > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > > Sent: Monday, March 24, 2008 2:31 PM
> > > To: ivy-user@ant.apache.org
> > > Subject: Re: specify versions separate from dependencies
> > >
> > > I've started working on this, and come close to a solution. To
> > > finalize my work, we need to decide upon the syntax we want to use
> > > in Ivy files to support transitive dependency override mechanism.
> > >
> > > After some more thoughts on the feature and how it relates to
> > > existing Ivy features, I think we now have 3 different ways to
> > > influence transitive dependencies in an Ivy file:
> > > - transitive dependency exclusion (IVY-431), introduced in
> > > 2.0.0-alpha1. This feature relies on an 'exclude' tag directly under
> > > the 'dependencies' element.
> > > - setting specific conflict managers for transitive dependencies.
> > > This relies on a 'conflicts' element and its child elements
> > > 'manager'.
> > > - overriding version and/or branch of transitive dependencies. In
> > > the implementation, I've opened the door to more feature than that,
> > > by implementing a dependency descriptor mediator mechanism.
> > > Whenever we load a module descriptor dependency descriptors to
> > > resolve them, we first ask all the dependers to mediate each
> > > dependency descriptor. Then we use the mediated dependency
> > > descriptor to resolve the dependency, instead of the original one.
> > > For the moment I've only implemented one mediator, called override.
> > > But we could later imagine other kinds of mediation which happens
> > > before actual dependency resolution. For the moment I've used this
> > > syntax for this new feature: <engine-hints>
> > > <mediation>
> > > <override org="yourorg" module=".*1" matcher="regexp"
> > > branch="BRANCH" rev="1.0" />
> > > </mediation>
> > > </engine-hints>
> > > This section is put directly under ivy-module element. What I would
> > > like to do is group the three kind of transitive dependencies hints
> > > we can give to the resolve engine in an ivy file. I'm still
> > > wondering what is the best syntax, and if we can afford deprecating
> > > the syntax of conflicts and module wide exclude. If we agree to
> > > deprecate them, here's one idea for the new syntax:
> > > <ivy-module>
> > > <dependencies>
> > > <dependency ... />
> > > <dependency ... />
> > > ...
> > > <hints>
> > > <exclude org="" module="" matcher="" ... />
> > > <conflict org="" module="" matcher="" rev|manager="" />
> > > <override org="" module="" matcher="" branch="" rev="" />
> > > </hints>
> > > </dependencies>
> > > </ivy-module>
> > > The conflict tag is similar to the current conflicts/manager tag,
> > > except that the 'name' attribute is replaced by 'manager'.
> > > All three kind of hints share the same attribute triple (org -
> > > module - matcher). The usage of this uple is slightly different in
> > > exclude, where it also applied to other attributes, such as artifact
> > > (to name the artifacts to exclude transitively).
> > >
> > > Another approach would be to put the hints section directly under
> > > ivy-module instead of under dependencies (as it's the case for
> > > conflicts/manager today). I think I prefer the former approach I
> > > propose.
> > >
> > > This is open to discussion, please give your feedback, once 2.0 will
> > > be out we won't be able to go back.
> > >
> > > Xavier
> > >
> > > On Wed, Feb 27, 2008 at 8:30 PM, Harald Braumann <ha...@unheit.net>
> > > wrote:
> > >
> > > > On Wed, 27 Feb 2008 14:23:50 +0100 "Xavier Hanin"
> > > > <xa...@gmail.com> wrote:
> > > >
> > > > > Could you open an issue about that?
> > > >
> > > > Here it is: https://issues.apache.org/jira/browse/IVY-753
> > > >
> > > > harry
> > > >
> > >
> > >
> > >
> > > --
> > > Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/
> > > http://ant.apache.org/ivy/ http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Harald Braumann <ha...@unheit.net>.
On Mon, 24 Mar 2008 14:48:11 -0400
Jim Adams <Ji...@sas.com> wrote:
> Is there any way to include this from another file? What I am
> thinking of is that we have a properties file filled with the default
> versions of third party dependencies that our build wants to use. We
> have different build tracks, corresponding to different installable
> portions of our system, where people may decide that they want to
> override the original third party dependencies.
I think property files are not flexible enough. There already was the
discussion about some kind of parent file where you can specify your
overrides. This could be included in the ivy file.
> It seems that this
> would be possible with this system. I am concerned that I will end up
> with conflicts, however, and not know it nor really understand the
> implications of these conflicts.
I don't see much difference to "normal" conflicts. If A depends on B
and C and both, B and C have overrides on D, than from the point of
view of A there are two possible versions for D which would have to be
resolved. Just the same as when there where two conflicting normal
transitive dependencies on D. With the override mechanism you can now
choose the version of D in A's ivy file or in its parent, if that
feature will be implemented.
harry
>
> > -----Original Message-----
> > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > Sent: Monday, March 24, 2008 2:31 PM
> > To: ivy-user@ant.apache.org
> > Subject: Re: specify versions separate from dependencies
> >
> > I've started working on this, and come close to a solution. To
> > finalize my work, we need to decide upon the syntax we want to use
> > in Ivy files to support transitive dependency override mechanism.
> >
> > After some more thoughts on the feature and how it relates to
> > existing Ivy features, I think we now have 3 different ways to
> > influence transitive dependencies in an Ivy file:
> > - transitive dependency exclusion (IVY-431), introduced in
> > 2.0.0-alpha1. This feature relies on an 'exclude' tag directly
> > under the 'dependencies' element.
> > - setting specific conflict managers for transitive dependencies.
> > This relies on a 'conflicts' element and its child elements
> > 'manager'.
> > - overriding version and/or branch of transitive dependencies. In
> > the implementation, I've opened the door to more feature than that,
> > by implementing a dependency descriptor mediator mechanism.
> > Whenever we load a module descriptor dependency descriptors to
> > resolve them, we first ask all the dependers to mediate each
> > dependency descriptor. Then we use the mediated dependency
> > descriptor to resolve the dependency, instead of the original one.
> > For the moment I've only implemented one mediator, called override.
> > But we could later imagine other kinds of mediation which happens
> > before actual dependency resolution. For the moment I've used this
> > syntax for this new feature: <engine-hints>
> > <mediation>
> > <override org="yourorg" module=".*1" matcher="regexp"
> > branch="BRANCH" rev="1.0" />
> > </mediation>
> > </engine-hints>
> > This section is put directly under ivy-module element. What I would
> > like to do is group the three kind of transitive dependencies hints
> > we can give to the resolve engine in an ivy file. I'm still
> > wondering what is the best syntax, and if we can afford deprecating
> > the syntax of conflicts and module wide exclude. If we agree to
> > deprecate them, here's one idea for the new syntax:
> > <ivy-module>
> > <dependencies>
> > <dependency ... />
> > <dependency ... />
> > ...
> > <hints>
> > <exclude org="" module="" matcher="" ... />
> > <conflict org="" module="" matcher="" rev|manager="" />
> > <override org="" module="" matcher="" branch="" rev="" />
> > </hints>
> > </dependencies>
> > </ivy-module>
> > The conflict tag is similar to the current conflicts/manager tag,
> > except that the 'name' attribute is replaced by 'manager'.
> > All three kind of hints share the same attribute triple (org -
> > module - matcher). The usage of this uple is slightly different in
> > exclude, where it also applied to other attributes, such as
> > artifact (to name the artifacts to exclude transitively).
> >
> > Another approach would be to put the hints section directly under
> > ivy-module instead of under dependencies (as it's the case for
> > conflicts/manager today). I think I prefer the former approach I
> > propose.
> >
> > This is open to discussion, please give your feedback, once 2.0
> > will be out we won't be able to go back.
> >
> > Xavier
> >
> > On Wed, Feb 27, 2008 at 8:30 PM, Harald Braumann <ha...@unheit.net>
> > wrote:
> >
> > > On Wed, 27 Feb 2008 14:23:50 +0100
> > > "Xavier Hanin" <xa...@gmail.com> wrote:
> > >
> > > > Could you open an issue about that?
> > >
> > > Here it is: https://issues.apache.org/jira/browse/IVY-753
> > >
> > > harry
> > >
> >
> >
> >
> > --
> > Xavier Hanin - Independent Java Consultant
> > http://xhab.blogspot.com/
> > http://ant.apache.org/ivy/
> > http://www.xoocode.org/
RE: specify versions separate from dependencies
Posted by Jim Adams <Ji...@sas.com>.
Is there any way to include this from another file? What I am thinking of is that we have a properties file filled with the default versions of third party dependencies that our build wants to use. We have different build tracks, corresponding to different installable portions of our system, where people may decide that they want to override the original third party dependencies. It seems that this would be possible with this system. I am concerned that I will end up with conflicts, however, and not know it nor really understand the implications of these conflicts.
> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: Monday, March 24, 2008 2:31 PM
> To: ivy-user@ant.apache.org
> Subject: Re: specify versions separate from dependencies
>
> I've started working on this, and come close to a solution. To finalize my
> work, we need to decide upon the syntax we want to use in Ivy files to
> support transitive dependency override mechanism.
>
> After some more thoughts on the feature and how it relates to existing Ivy
> features, I think we now have 3 different ways to influence transitive
> dependencies in an Ivy file:
> - transitive dependency exclusion (IVY-431), introduced in 2.0.0-alpha1.
> This feature relies on an 'exclude' tag directly under the 'dependencies'
> element.
> - setting specific conflict managers for transitive dependencies. This
> relies on a 'conflicts' element and its child elements 'manager'.
> - overriding version and/or branch of transitive dependencies. In the
> implementation, I've opened the door to more feature than that, by
> implementing a dependency descriptor mediator mechanism. Whenever we load a
> module descriptor dependency descriptors to resolve them, we first ask all
> the dependers to mediate each dependency descriptor. Then we use the
> mediated dependency descriptor to resolve the dependency, instead of the
> original one. For the moment I've only implemented one mediator, called
> override. But we could later imagine other kinds of mediation which happens
> before actual dependency resolution. For the moment I've used this syntax
> for this new feature:
> <engine-hints>
> <mediation>
> <override org="yourorg" module=".*1" matcher="regexp"
> branch="BRANCH" rev="1.0" />
> </mediation>
> </engine-hints>
> This section is put directly under ivy-module element. What I would like to
> do is group the three kind of transitive dependencies hints we can give to
> the resolve engine in an ivy file. I'm still wondering what is the best
> syntax, and if we can afford deprecating the syntax of conflicts and module
> wide exclude. If we agree to deprecate them, here's one idea for the new
> syntax:
> <ivy-module>
> <dependencies>
> <dependency ... />
> <dependency ... />
> ...
> <hints>
> <exclude org="" module="" matcher="" ... />
> <conflict org="" module="" matcher="" rev|manager="" />
> <override org="" module="" matcher="" branch="" rev="" />
> </hints>
> </dependencies>
> </ivy-module>
> The conflict tag is similar to the current conflicts/manager tag, except
> that the 'name' attribute is replaced by 'manager'.
> All three kind of hints share the same attribute triple (org - module -
> matcher). The usage of this uple is slightly different in exclude, where it
> also applied to other attributes, such as artifact (to name the artifacts to
> exclude transitively).
>
> Another approach would be to put the hints section directly under ivy-module
> instead of under dependencies (as it's the case for conflicts/manager
> today). I think I prefer the former approach I propose.
>
> This is open to discussion, please give your feedback, once 2.0 will be out
> we won't be able to go back.
>
> Xavier
>
> On Wed, Feb 27, 2008 at 8:30 PM, Harald Braumann <ha...@unheit.net> wrote:
>
> > On Wed, 27 Feb 2008 14:23:50 +0100
> > "Xavier Hanin" <xa...@gmail.com> wrote:
> >
> > > Could you open an issue about that?
> >
> > Here it is: https://issues.apache.org/jira/browse/IVY-753
> >
> > harry
> >
>
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Mon, Mar 24, 2008 at 8:29 PM, Harald Braumann <ha...@unheit.net> wrote:
> On Mon, 24 Mar 2008 19:30:49 +0100
> "Xavier Hanin" <xa...@gmail.com> wrote:
>
> > I've started working on this, and come close to a solution. To
> > finalize my work, we need to decide upon the syntax we want to use in
> > Ivy files to support transitive dependency override mechanism.
> Great.
>
> > After some more thoughts on the feature and how it relates to
> > existing Ivy features, I think we now have 3 different ways to
> > influence transitive dependencies in an Ivy file:
> > - transitive dependency exclusion (IVY-431), introduced in
> > 2.0.0-alpha1. This feature relies on an 'exclude' tag directly under
> > the 'dependencies' element.
> This would get very complex. Because of just saying, I want foo 1.0,
> I'd have to check which versions would be actual candidates and then
> exclude all of them. If something changes down the tree, I'd have to
> recheck and add additional excludes.
This is already implemented, and is not used for the same purpose. I was
just stating all the features Ivy implements which deals with transitive
dependencies control.
>
>
> > - setting specific conflict managers for transitive dependencies. This
> > relies on a 'conflicts' element and its child elements 'manager'.
> > - overriding version and/or branch of transitive dependencies. In the
> > implementation, I've opened the door to more feature than that, by
> > implementing a dependency descriptor mediator mechanism. Whenever we
> > load a module descriptor dependency descriptors to resolve them, we
> > first ask all the dependers to mediate each dependency descriptor.
> > Then we use the mediated dependency descriptor to resolve the
> > dependency, instead of the original one. For the moment I've only
> > implemented one mediator, called override. But we could later imagine
> > other kinds of mediation which happens before actual dependency
> > resolution. For the moment I've used this syntax for this new feature:
> > <engine-hints>
> > <mediation>
> > <override org="yourorg" module=".*1" matcher="regexp"
> > branch="BRANCH" rev="1.0" />
> > </mediation>
> > </engine-hints>
> > This section is put directly under ivy-module element. What I would
> > like to do is group the three kind of transitive dependencies hints
> > we can give to the resolve engine in an ivy file. I'm still wondering
> > what is the best syntax, and if we can afford deprecating the syntax
> > of conflicts and module wide exclude. If we agree to deprecate them,
> > here's one idea for the new syntax:
> > <ivy-module>
> > <dependencies>
> > <dependency ... />
> > <dependency ... />
> > ...
> > <hints>
> > <exclude org="" module="" matcher="" ... />
> > <conflict org="" module="" matcher="" rev|manager="" />
> > <override org="" module="" matcher="" branch="" rev="" />
> > </hints>
> > </dependencies>
> > </ivy-module>
> > The conflict tag is similar to the current conflicts/manager tag,
> > except that the 'name' attribute is replaced by 'manager'.
> > All three kind of hints share the same attribute triple (org - module
> > - matcher). The usage of this uple is slightly different in exclude,
> > where it also applied to other attributes, such as artifact (to name
> > the artifacts to exclude transitively).
> Sounds like a good and flexible solution. From what I understand,
> that's what your prototype currently does?
My prototype actually use the first syntax I've given:
<engine-hints>
<mediation>
<override org="yourorg" module=".*1" matcher="regexp"
branch="BRANCH" rev="1.0" />
</mediation>
</engine-hints>
But I don't really like it, I'd prefer the second one I give, but which
require changes for exclude and conflicts/manager, and thus deprecating old
syntax. Therefore I ask for feedback on this from the community.
Xavier
>
>
> > Another approach would be to put the hints section directly under
> > ivy-module instead of under dependencies (as it's the case for
> > conflicts/manager today). I think I prefer the former approach I
> > propose.
> >
> > This is open to discussion, please give your feedback, once 2.0 will
> > be out we won't be able to go back.
> >
> > Xavier
> >
> harry
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Harald Braumann <ha...@unheit.net>.
On Mon, 24 Mar 2008 19:30:49 +0100
"Xavier Hanin" <xa...@gmail.com> wrote:
> I've started working on this, and come close to a solution. To
> finalize my work, we need to decide upon the syntax we want to use in
> Ivy files to support transitive dependency override mechanism.
Great.
> After some more thoughts on the feature and how it relates to
> existing Ivy features, I think we now have 3 different ways to
> influence transitive dependencies in an Ivy file:
> - transitive dependency exclusion (IVY-431), introduced in
> 2.0.0-alpha1. This feature relies on an 'exclude' tag directly under
> the 'dependencies' element.
This would get very complex. Because of just saying, I want foo 1.0,
I'd have to check which versions would be actual candidates and then
exclude all of them. If something changes down the tree, I'd have to
recheck and add additional excludes.
> - setting specific conflict managers for transitive dependencies. This
> relies on a 'conflicts' element and its child elements 'manager'.
> - overriding version and/or branch of transitive dependencies. In the
> implementation, I've opened the door to more feature than that, by
> implementing a dependency descriptor mediator mechanism. Whenever we
> load a module descriptor dependency descriptors to resolve them, we
> first ask all the dependers to mediate each dependency descriptor.
> Then we use the mediated dependency descriptor to resolve the
> dependency, instead of the original one. For the moment I've only
> implemented one mediator, called override. But we could later imagine
> other kinds of mediation which happens before actual dependency
> resolution. For the moment I've used this syntax for this new feature:
> <engine-hints>
> <mediation>
> <override org="yourorg" module=".*1" matcher="regexp"
> branch="BRANCH" rev="1.0" />
> </mediation>
> </engine-hints>
> This section is put directly under ivy-module element. What I would
> like to do is group the three kind of transitive dependencies hints
> we can give to the resolve engine in an ivy file. I'm still wondering
> what is the best syntax, and if we can afford deprecating the syntax
> of conflicts and module wide exclude. If we agree to deprecate them,
> here's one idea for the new syntax:
> <ivy-module>
> <dependencies>
> <dependency ... />
> <dependency ... />
> ...
> <hints>
> <exclude org="" module="" matcher="" ... />
> <conflict org="" module="" matcher="" rev|manager="" />
> <override org="" module="" matcher="" branch="" rev="" />
> </hints>
> </dependencies>
> </ivy-module>
> The conflict tag is similar to the current conflicts/manager tag,
> except that the 'name' attribute is replaced by 'manager'.
> All three kind of hints share the same attribute triple (org - module
> - matcher). The usage of this uple is slightly different in exclude,
> where it also applied to other attributes, such as artifact (to name
> the artifacts to exclude transitively).
Sounds like a good and flexible solution. From what I understand,
that's what your prototype currently does?
> Another approach would be to put the hints section directly under
> ivy-module instead of under dependencies (as it's the case for
> conflicts/manager today). I think I prefer the former approach I
> propose.
>
> This is open to discussion, please give your feedback, once 2.0 will
> be out we won't be able to go back.
>
> Xavier
>
harry
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
I forward this message to dev list, since I would really like to get some
feedback from Ivy committers on the syntax to use for this feature.
On Mon, Mar 24, 2008 at 7:30 PM, Xavier Hanin <xa...@gmail.com>
wrote:
> I've started working on this, and come close to a solution. To finalize my
> work, we need to decide upon the syntax we want to use in Ivy files to
> support transitive dependency override mechanism.
>
> After some more thoughts on the feature and how it relates to existing Ivy
> features, I think we now have 3 different ways to influence transitive
> dependencies in an Ivy file:
> - transitive dependency exclusion (IVY-431), introduced in 2.0.0-alpha1.
> This feature relies on an 'exclude' tag directly under the 'dependencies'
> element.
> - setting specific conflict managers for transitive dependencies. This
> relies on a 'conflicts' element and its child elements 'manager'.
> - overriding version and/or branch of transitive dependencies. In the
> implementation, I've opened the door to more feature than that, by
> implementing a dependency descriptor mediator mechanism. Whenever we load a
> module descriptor dependency descriptors to resolve them, we first ask all
> the dependers to mediate each dependency descriptor. Then we use the
> mediated dependency descriptor to resolve the dependency, instead of the
> original one. For the moment I've only implemented one mediator, called
> override. But we could later imagine other kinds of mediation which happens
> before actual dependency resolution. For the moment I've used this syntax
> for this new feature:
> <engine-hints>
> <mediation>
> <override org="yourorg" module=".*1" matcher="regexp"
> branch="BRANCH" rev="1.0" />
> </mediation>
> </engine-hints>
> This section is put directly under ivy-module element. What I would like
> to do is group the three kind of transitive dependencies hints we can give
> to the resolve engine in an ivy file. I'm still wondering what is the best
> syntax, and if we can afford deprecating the syntax of conflicts and module
> wide exclude. If we agree to deprecate them, here's one idea for the new
> syntax:
> <ivy-module>
> <dependencies>
> <dependency ... />
> <dependency ... />
> ...
> <hints>
> <exclude org="" module="" matcher="" ... />
> <conflict org="" module="" matcher="" rev|manager="" />
> <override org="" module="" matcher="" branch="" rev="" />
> </hints>
> </dependencies>
> </ivy-module>
> The conflict tag is similar to the current conflicts/manager tag, except
> that the 'name' attribute is replaced by 'manager'.
> All three kind of hints share the same attribute triple (org - module -
> matcher). The usage of this uple is slightly different in exclude, where it
> also applied to other attributes, such as artifact (to name the artifacts to
> exclude transitively).
>
> Another approach would be to put the hints section directly under
> ivy-module instead of under dependencies (as it's the case for
> conflicts/manager today). I think I prefer the former approach I propose.
>
> This is open to discussion, please give your feedback, once 2.0 will be
> out we won't be able to go back.
>
> Xavier
>
>
> On Wed, Feb 27, 2008 at 8:30 PM, Harald Braumann <ha...@unheit.net> wrote:
>
> > On Wed, 27 Feb 2008 14:23:50 +0100
> > "Xavier Hanin" <xa...@gmail.com> wrote:
> >
> > > Could you open an issue about that?
> >
> > Here it is: https://issues.apache.org/jira/browse/IVY-753
> >
> > harry
> >
>
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
I've started working on this, and come close to a solution. To finalize my
work, we need to decide upon the syntax we want to use in Ivy files to
support transitive dependency override mechanism.
After some more thoughts on the feature and how it relates to existing Ivy
features, I think we now have 3 different ways to influence transitive
dependencies in an Ivy file:
- transitive dependency exclusion (IVY-431), introduced in 2.0.0-alpha1.
This feature relies on an 'exclude' tag directly under the 'dependencies'
element.
- setting specific conflict managers for transitive dependencies. This
relies on a 'conflicts' element and its child elements 'manager'.
- overriding version and/or branch of transitive dependencies. In the
implementation, I've opened the door to more feature than that, by
implementing a dependency descriptor mediator mechanism. Whenever we load a
module descriptor dependency descriptors to resolve them, we first ask all
the dependers to mediate each dependency descriptor. Then we use the
mediated dependency descriptor to resolve the dependency, instead of the
original one. For the moment I've only implemented one mediator, called
override. But we could later imagine other kinds of mediation which happens
before actual dependency resolution. For the moment I've used this syntax
for this new feature:
<engine-hints>
<mediation>
<override org="yourorg" module=".*1" matcher="regexp"
branch="BRANCH" rev="1.0" />
</mediation>
</engine-hints>
This section is put directly under ivy-module element. What I would like to
do is group the three kind of transitive dependencies hints we can give to
the resolve engine in an ivy file. I'm still wondering what is the best
syntax, and if we can afford deprecating the syntax of conflicts and module
wide exclude. If we agree to deprecate them, here's one idea for the new
syntax:
<ivy-module>
<dependencies>
<dependency ... />
<dependency ... />
...
<hints>
<exclude org="" module="" matcher="" ... />
<conflict org="" module="" matcher="" rev|manager="" />
<override org="" module="" matcher="" branch="" rev="" />
</hints>
</dependencies>
</ivy-module>
The conflict tag is similar to the current conflicts/manager tag, except
that the 'name' attribute is replaced by 'manager'.
All three kind of hints share the same attribute triple (org - module -
matcher). The usage of this uple is slightly different in exclude, where it
also applied to other attributes, such as artifact (to name the artifacts to
exclude transitively).
Another approach would be to put the hints section directly under ivy-module
instead of under dependencies (as it's the case for conflicts/manager
today). I think I prefer the former approach I propose.
This is open to discussion, please give your feedback, once 2.0 will be out
we won't be able to go back.
Xavier
On Wed, Feb 27, 2008 at 8:30 PM, Harald Braumann <ha...@unheit.net> wrote:
> On Wed, 27 Feb 2008 14:23:50 +0100
> "Xavier Hanin" <xa...@gmail.com> wrote:
>
> > Could you open an issue about that?
>
> Here it is: https://issues.apache.org/jira/browse/IVY-753
>
> harry
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Harald Braumann <ha...@unheit.net>.
On Wed, 27 Feb 2008 14:23:50 +0100
"Xavier Hanin" <xa...@gmail.com> wrote:
> Could you open an issue about that?
Here it is: https://issues.apache.org/jira/browse/IVY-753
harry
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Wed, Feb 27, 2008 at 7:17 PM, Harald Braumann <ha...@unheit.net> wrote:
> On Wed, 27 Feb 2008 18:56:44 +0100
> "Xavier Hanin" <xa...@gmail.com> wrote:
>
> > On Wed, Feb 27, 2008 at 6:47 PM, Niklas Matthies
> > <ml...@nmhq.net> wrote:
> >
> > > Also the name "dependencyManagement" is really, really bad. :)
> > > *Everything* in an ivy file is about dependendency management.
> > > At least make it "dependency-override" or something like that.
> > >
> > > [Note: I've never used Maven. Adopting non-descriptive names from
> > > Maven just to make Maven users feel more comfortable with a feature
> > > which (probably) does almost-but-not-exactly the same thing as in
> > > Maven feels like a really bad trade-off to me. ;)]
> >
> > I agree, it's a bad idea. dependency-override sounds like a much
> > better name, if we only put dependency overriding here. Someone
> > suggested to merge the conflicts/manager with this, since both
> > actually tweak the way transitive dependencies are handled. Maybe we
> > could find a better and more explicit syntax which could address both
> > concerns? Suggestions, anyone?
> >
> I, too, agree that dependencyManagement is not the best of all names.
> And also note that I'm looking into ivy because I'm not satisfied with
> maven. So by all means, don't try to copy maven.
Copying the good is not a bad thing :-). And for this I think maven has more
flexibility than we have which can be useful to our users too. But this
discussion is really interesting, I already feel like we'll finally end up
with something clean, powerful and flexible in Ivy to handle this.
Xavier
I just used it as an
> example because it's the system I know.
>
> harry
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Harald Braumann <ha...@unheit.net>.
On Wed, 27 Feb 2008 18:56:44 +0100
"Xavier Hanin" <xa...@gmail.com> wrote:
> On Wed, Feb 27, 2008 at 6:47 PM, Niklas Matthies
> <ml...@nmhq.net> wrote:
>
> > Also the name "dependencyManagement" is really, really bad. :)
> > *Everything* in an ivy file is about dependendency management.
> > At least make it "dependency-override" or something like that.
> >
> > [Note: I've never used Maven. Adopting non-descriptive names from
> > Maven just to make Maven users feel more comfortable with a feature
> > which (probably) does almost-but-not-exactly the same thing as in
> > Maven feels like a really bad trade-off to me. ;)]
>
> I agree, it's a bad idea. dependency-override sounds like a much
> better name, if we only put dependency overriding here. Someone
> suggested to merge the conflicts/manager with this, since both
> actually tweak the way transitive dependencies are handled. Maybe we
> could find a better and more explicit syntax which could address both
> concerns? Suggestions, anyone?
>
I, too, agree that dependencyManagement is not the best of all names.
And also note that I'm looking into ivy because I'm not satisfied with
maven. So by all means, don't try to copy maven. I just used it as an
example because it's the system I know.
harry
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Wed, Feb 27, 2008 at 8:05 PM, Niklas Matthies <ml...@nmhq.net>
wrote:
> On Wed 2008-02-27 at 18:56h, Xavier Hanin wrote on ivy-user:
> :
> > Mm, we currently use dependencies/dependency only for direct
> > dependencies. And this is not a direct dependency. So I'd really
> > prefer to keep it separated, as the conflicts section.
>
> Scott Oster hits the nail on the head when he says that it's actually
> a revision constraint. It occurs to me that it might generally be
> helpful to distinguish between dependencies ("module A requires
> module B, period") and revision constraints ("module A only works with
> revisions x to y of module B (not necessarily implying that A requires
> B)").
>
> You might remember our discussion where I wanted (for the purpose of
> build reproducability) the earliest, rather than the latest, revision
> to be retrieved that matches specific version constraints. The problem
> there was as well that a corresponding conflict manager would only
> kick in when there's an actual conflict. Maybe what we really need is
> a "revision selector" which selects one or more revisions from the set
> of revisions that is the intersection between the set of revisions
> available in the repository and the set defined by the revision
> constraints. (This has aspects from both latest-strategy and conflict
> managers.) An actual conflict manager would only kick in when the set
> defined by the version constraints becomes empty, i.e. when there is a
> conflict between the *constraints* imposed by (different) dependent
> modules.
This sounds interesting. This requires more thinking, to see what could
really be achieved with that. I guess you already have a pretty good idea,
I'm looking forward to have more details about what you envision and the
associated use cases.
Xavier
>
>
> I need to think a bit about how this could be made efficient in terms
> of minimizing ivy file retrievals. (I'm pretty certain it can.)
>
> -- Niklas Matthies
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Niklas Matthies <ml...@nmhq.net>.
On Wed 2008-02-27 at 18:56h, Xavier Hanin wrote on ivy-user:
:
> Mm, we currently use dependencies/dependency only for direct
> dependencies. And this is not a direct dependency. So I'd really
> prefer to keep it separated, as the conflicts section.
Scott Oster hits the nail on the head when he says that it's actually
a revision constraint. It occurs to me that it might generally be
helpful to distinguish between dependencies ("module A requires
module B, period") and revision constraints ("module A only works with
revisions x to y of module B (not necessarily implying that A requires
B)").
You might remember our discussion where I wanted (for the purpose of
build reproducability) the earliest, rather than the latest, revision
to be retrieved that matches specific version constraints. The problem
there was as well that a corresponding conflict manager would only
kick in when there's an actual conflict. Maybe what we really need is
a "revision selector" which selects one or more revisions from the set
of revisions that is the intersection between the set of revisions
available in the repository and the set defined by the revision
constraints. (This has aspects from both latest-strategy and conflict
managers.) An actual conflict manager would only kick in when the set
defined by the version constraints becomes empty, i.e. when there is a
conflict between the *constraints* imposed by (different) dependent
modules.
I need to think a bit about how this could be made efficient in terms
of minimizing ivy file retrievals. (I'm pretty certain it can.)
-- Niklas Matthies
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Wed, Feb 27, 2008 at 6:47 PM, Niklas Matthies <ml...@nmhq.net>
wrote:
> On Wed 2008-02-27 at 17:04h, Xavier Hanin wrote on ivy-user:
> > On Wed, Feb 27, 2008 at 4:59 PM, Niklas Matthies wrote:
> :
> > > How would this be different from a regular dependency with a "force"
> > > attribute?
> >
> > It's different only in concept: I don't like having to add a dependency
> > declaration when your module don't actually depend on something. Later
> you
> > can wonder why you have this dependency. That's why we have the
> conflicts
> > section in Ivy files. So I think this kind of dependency version
> overloading
> > deserves a new feature.
>
> Okay, then how about adding an "override-only" attribute to dependency
> declarations? Or as a new value of the "transitive" attribute (i.e.
> transitive="override-only"). My feeling is that the feature has too
> much in common with real dependencies. (It actually *is* a dependency
> in the sense of demanding a particuar revision.) Every new feature
> added to "dependency" that is also applicable to the revision override
> features (like branches and extra attributes) would have to be carried
> over, and documented separately. Or else the feature set diverges over
> time.
Mm, we currently use dependencies/dependency only for direct dependencies.
And this is not a direct dependency. So I'd really prefer to keep it
separated, as the conflicts section.
>
> Also the name "dependencyManagement" is really, really bad. :)
> *Everything* in an ivy file is about dependendency management.
> At least make it "dependency-override" or something like that.
>
> [Note: I've never used Maven. Adopting non-descriptive names from
> Maven just to make Maven users feel more comfortable with a feature
> which (probably) does almost-but-not-exactly the same thing as in
> Maven feels like a really bad trade-off to me. ;)]
I agree, it's a bad idea. dependency-override sounds like a much better
name, if we only put dependency overriding here. Someone suggested to merge
the conflicts/manager with this, since both actually tweak the way
transitive dependencies are handled. Maybe we could find a better and more
explicit syntax which could address both concerns? Suggestions, anyone?
Xavier
>
>
> -- Niklas Matthies
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Niklas Matthies <ml...@nmhq.net>.
On Wed 2008-02-27 at 17:04h, Xavier Hanin wrote on ivy-user:
> On Wed, Feb 27, 2008 at 4:59 PM, Niklas Matthies wrote:
:
> > How would this be different from a regular dependency with a "force"
> > attribute?
>
> It's different only in concept: I don't like having to add a dependency
> declaration when your module don't actually depend on something. Later you
> can wonder why you have this dependency. That's why we have the conflicts
> section in Ivy files. So I think this kind of dependency version overloading
> deserves a new feature.
Okay, then how about adding an "override-only" attribute to dependency
declarations? Or as a new value of the "transitive" attribute (i.e.
transitive="override-only"). My feeling is that the feature has too
much in common with real dependencies. (It actually *is* a dependency
in the sense of demanding a particuar revision.) Every new feature
added to "dependency" that is also applicable to the revision override
features (like branches and extra attributes) would have to be carried
over, and documented separately. Or else the feature set diverges over
time.
Also the name "dependencyManagement" is really, really bad. :)
*Everything* in an ivy file is about dependendency management.
At least make it "dependency-override" or something like that.
[Note: I've never used Maven. Adopting non-descriptive names from
Maven just to make Maven users feel more comfortable with a feature
which (probably) does almost-but-not-exactly the same thing as in
Maven feels like a really bad trade-off to me. ;)]
-- Niklas Matthies
Re: specify versions separate from dependencies
Posted by Harald Braumann <ha...@unheit.net>.
On Wed, 27 Feb 2008 17:04:24 +0100
"Xavier Hanin" <xa...@gmail.com> wrote:
> On Wed, Feb 27, 2008 at 4:59 PM, Niklas Matthies
> <ml...@nmhq.net> wrote:
>
> > On Wed 2008-02-27 at 16:50h, Xavier Hanin wrote on ivy-user:
> > :
> > > Personnally I was just thinking about something very similar to
> > > maven dependency management feature, with slight adaptation to
> > > Ivy syntax.
> > >
> > > Something like:
> > > <ivy-module version="2.0">
> > > <info ... />
> > > <dependencies>
> > > </dependencies>
> > > <dependencyManagement>
> > > <dependency org="foo" name="bar" rev="1.0" />
> > > </dependencyManagement>
> > > </ivy-module>
> >
> > How would this be different from a regular dependency with a "force"
> > attribute?
>
> It's different only in concept: I don't like having to add a
> dependency declaration when your module don't actually depend on
> something. Later you can wonder why you have this dependency. That's
> why we have the conflicts section in Ivy files. So I think this kind
> of dependency version overloading deserves a new feature.
>
Full ACK.
harry
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Wed, Feb 27, 2008 at 4:59 PM, Niklas Matthies <ml...@nmhq.net>
wrote:
> On Wed 2008-02-27 at 16:50h, Xavier Hanin wrote on ivy-user:
> :
> > Personnally I was just thinking about something very similar to maven
> > dependency management feature, with slight adaptation to Ivy syntax.
> >
> > Something like:
> > <ivy-module version="2.0">
> > <info ... />
> > <dependencies>
> > </dependencies>
> > <dependencyManagement>
> > <dependency org="foo" name="bar" rev="1.0" />
> > </dependencyManagement>
> > </ivy-module>
>
> How would this be different from a regular dependency with a "force"
> attribute?
It's different only in concept: I don't like having to add a dependency
declaration when your module don't actually depend on something. Later you
can wonder why you have this dependency. That's why we have the conflicts
section in Ivy files. So I think this kind of dependency version overloading
deserves a new feature.
Xavier
>
>
> -- Niklas Matthies
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Niklas Matthies <ml...@nmhq.net>.
On Wed 2008-02-27 at 16:50h, Xavier Hanin wrote on ivy-user:
:
> Personnally I was just thinking about something very similar to maven
> dependency management feature, with slight adaptation to Ivy syntax.
>
> Something like:
> <ivy-module version="2.0">
> <info ... />
> <dependencies>
> </dependencies>
> <dependencyManagement>
> <dependency org="foo" name="bar" rev="1.0" />
> </dependencyManagement>
> </ivy-module>
How would this be different from a regular dependency with a "force"
attribute?
-- Niklas Matthies
Re: specify versions separate from dependencies
Posted by Harald Braumann <ha...@unheit.net>.
On Wed, 27 Feb 2008 19:45:41 +0100
"Xavier Hanin" <xa...@gmail.com> wrote:
> On Wed, Feb 27, 2008 at 7:32 PM, Harald Braumann <ha...@unheit.net>
> wrote:
>
> > On Wed, 27 Feb 2008 18:51:14 +0100
> > "Xavier Hanin" <xa...@gmail.com> wrote:
> >
> > > On Wed, Feb 27, 2008 at 6:11 PM, Harald Braumann
> > > <ha...@unheit.net> wrote:
> > >
> > > > Sorry, I misunderstood you before. You put the overrides in the
> > > > ivy file directly. In this case you're right, of course. I
> > > > thought of foo#bar more like the parent pom in maven
> > > > nomenclature.
> > > >
> > > > In your proposal it would be nice, if dependencyManagement
> > > > would be resolved recursively. This would help multi-module
> > > > projects, where you want to define versions centrally in a
> > > > single file. You could then specify a module without
> > > > publications (thus I thought of a virtual module) and with only
> > > > a dependencyMangement section. Like so:
> > > >
> > > > <ivy-module version="2.0">
> > > > <info organisation="acme" name="myproject" />
> > > > <dependencies>
> > > > </dependencies>
> > > > <dependencyManagement>
> > > > <dependency org="foo" name="bar" rev="1.0" />
> > > > <dependency org="foo" name="baz" rev="1.0" />
> > > > </dependencyManagement>
> > > > </ivy-module>
> > > >
> > > > <ivy-module version="2.0">
> > > > <info organisation="acme" name="mymodule1" />
> > > > <dependencies>
> > > > ...
> > > > </dependencies>
> > > > <dependencyManagement>
> > > > <dependency org="acme" name="myproject"
> > > > rev="latest.integration" /> </dependencyManagement>
> > > > </ivy-module>
> > > >
> > > > <ivy-module version="2.0">
> > > > <info organisation="acme" name="mymodule2" />
> > > > <dependencies>
> > > > ...
> > > > </dependencies>
> > > > <dependencyManagement>
> > > > <dependency org="acme" name="myproject"
> > > > rev="latest.integration" /> </dependencyManagement>
> > > > </ivy-module>
> > > >
> > > > And thus both, mymodule1 and mymodule2, would use the same
> > > > versions of foo#bar and foo#baz.
> > >
> > > I'm not sure to follow you. In acme#myproject, the
> > > dependencyManagement section is used to override dependencies, ok.
> > > But then in acme#mymodule(1|2) it's used (with the same syntax)
> > > as a kind of import or include mechanism, right? How do we
> > > distinguish between the two?
> > In the same way as it is done with dependencies. If mymodule1
> > depends on foo#bar, it uses foo#bar and at the same time includes
> > all the dependencies of foo#bar, recursively. Similarly, mymodule1
> > overrides any dependency of acme#myproject (acme#myproject is just
> > meant as a helper module to specify overrides in a single file, so
> > its probably not useful for any package to really depend on it) and
> > additionally includes all overrides from acme#myproject.
>
> I still have a problem to envision how we could code that: in my
> mind, when Ivy finds a "dependencyManagement" (better name to be
> chosen) section, it fills a data structure which is used when
> resolving dependencies transitively. But it doesn't actually resolve
> this as a dependency. So Ivy has no way to know that you actually
> want to resolve acme#myproject, and use its dependencyManagement
> section. What I could understand is if you'd use a different syntax
> to inform you want to use the dependencyManagement section of
> myproject, or if you use a regular dependency on myproject. For the
> latter, I wouldn't like to see this, since it would mean that a
> dependency (myproject) could influence the way other dependencies
> from the depender are resolved. You can answer that this is already
> the case when there's a conflict, but it's a different case, because
> conflict management end up to the depender's responsibility, even
> though this is hidden in most cases.
>
> But I think we have a pretty decent solution:
> - add a new section (good name still to be found) allowing to define
> dependency overrides (revision, branch, extra attributes)
ACK.
> - add a kind of parent/include mechanism (but only for root ivy files
> being resolved, files in repository would be merged to avoid complex
> location mechanism)
>
> Does it sound good?
Yes, that sounds very good.
harry
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Wed, Feb 27, 2008 at 7:32 PM, Harald Braumann <ha...@unheit.net> wrote:
> On Wed, 27 Feb 2008 18:51:14 +0100
> "Xavier Hanin" <xa...@gmail.com> wrote:
>
> > On Wed, Feb 27, 2008 at 6:11 PM, Harald Braumann <ha...@unheit.net>
> > wrote:
> >
> > > Sorry, I misunderstood you before. You put the overrides in the ivy
> > > file directly. In this case you're right, of course. I thought of
> > > foo#bar more like the parent pom in maven nomenclature.
> > >
> > > In your proposal it would be nice, if dependencyManagement would be
> > > resolved recursively. This would help multi-module projects, where
> > > you want to define versions centrally in a single file. You could
> > > then specify a module without publications (thus I thought of a
> > > virtual module) and with only a dependencyMangement section. Like
> > > so:
> > >
> > > <ivy-module version="2.0">
> > > <info organisation="acme" name="myproject" />
> > > <dependencies>
> > > </dependencies>
> > > <dependencyManagement>
> > > <dependency org="foo" name="bar" rev="1.0" />
> > > <dependency org="foo" name="baz" rev="1.0" />
> > > </dependencyManagement>
> > > </ivy-module>
> > >
> > > <ivy-module version="2.0">
> > > <info organisation="acme" name="mymodule1" />
> > > <dependencies>
> > > ...
> > > </dependencies>
> > > <dependencyManagement>
> > > <dependency org="acme" name="myproject"
> > > rev="latest.integration" /> </dependencyManagement>
> > > </ivy-module>
> > >
> > > <ivy-module version="2.0">
> > > <info organisation="acme" name="mymodule2" />
> > > <dependencies>
> > > ...
> > > </dependencies>
> > > <dependencyManagement>
> > > <dependency org="acme" name="myproject"
> > > rev="latest.integration" /> </dependencyManagement>
> > > </ivy-module>
> > >
> > > And thus both, mymodule1 and mymodule2, would use the same versions
> > > of foo#bar and foo#baz.
> >
> > I'm not sure to follow you. In acme#myproject, the
> > dependencyManagement section is used to override dependencies, ok.
> > But then in acme#mymodule(1|2) it's used (with the same syntax) as a
> > kind of import or include mechanism, right? How do we distinguish
> > between the two?
> In the same way as it is done with dependencies. If mymodule1 depends
> on foo#bar, it uses foo#bar and at the same time includes all the
> dependencies of foo#bar, recursively. Similarly, mymodule1 overrides
> any dependency of acme#myproject (acme#myproject is just meant as a
> helper module to specify overrides in a single file, so its probably
> not useful for any package to really depend on it) and additionally
> includes all overrides from acme#myproject.
I still have a problem to envision how we could code that: in my mind, when
Ivy finds a "dependencyManagement" (better name to be chosen) section, it
fills a data structure which is used when resolving dependencies
transitively. But it doesn't actually resolve this as a dependency. So Ivy
has no way to know that you actually want to resolve acme#myproject, and use
its dependencyManagement section. What I could understand is if you'd use a
different syntax to inform you want to use the dependencyManagement section
of myproject, or if you use a regular dependency on myproject. For the
latter, I wouldn't like to see this, since it would mean that a dependency
(myproject) could influence the way other dependencies from the depender are
resolved. You can answer that this is already the case when there's a
conflict, but it's a different case, because conflict management end up to
the depender's responsibility, even though this is hidden in most cases.
But I think we have a pretty decent solution:
- add a new section (good name still to be found) allowing to define
dependency overrides (revision, branch, extra attributes)
- add a kind of parent/include mechanism (but only for root ivy files being
resolved, files in repository would be merged to avoid complex location
mechanism)
Does it sound good?
Xavier
>
> harry
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Harald Braumann <ha...@unheit.net>.
On Wed, 27 Feb 2008 18:51:14 +0100
"Xavier Hanin" <xa...@gmail.com> wrote:
> On Wed, Feb 27, 2008 at 6:11 PM, Harald Braumann <ha...@unheit.net>
> wrote:
>
> > Sorry, I misunderstood you before. You put the overrides in the ivy
> > file directly. In this case you're right, of course. I thought of
> > foo#bar more like the parent pom in maven nomenclature.
> >
> > In your proposal it would be nice, if dependencyManagement would be
> > resolved recursively. This would help multi-module projects, where
> > you want to define versions centrally in a single file. You could
> > then specify a module without publications (thus I thought of a
> > virtual module) and with only a dependencyMangement section. Like
> > so:
> >
> > <ivy-module version="2.0">
> > <info organisation="acme" name="myproject" />
> > <dependencies>
> > </dependencies>
> > <dependencyManagement>
> > <dependency org="foo" name="bar" rev="1.0" />
> > <dependency org="foo" name="baz" rev="1.0" />
> > </dependencyManagement>
> > </ivy-module>
> >
> > <ivy-module version="2.0">
> > <info organisation="acme" name="mymodule1" />
> > <dependencies>
> > ...
> > </dependencies>
> > <dependencyManagement>
> > <dependency org="acme" name="myproject"
> > rev="latest.integration" /> </dependencyManagement>
> > </ivy-module>
> >
> > <ivy-module version="2.0">
> > <info organisation="acme" name="mymodule2" />
> > <dependencies>
> > ...
> > </dependencies>
> > <dependencyManagement>
> > <dependency org="acme" name="myproject"
> > rev="latest.integration" /> </dependencyManagement>
> > </ivy-module>
> >
> > And thus both, mymodule1 and mymodule2, would use the same versions
> > of foo#bar and foo#baz.
>
> I'm not sure to follow you. In acme#myproject, the
> dependencyManagement section is used to override dependencies, ok.
> But then in acme#mymodule(1|2) it's used (with the same syntax) as a
> kind of import or include mechanism, right? How do we distinguish
> between the two?
In the same way as it is done with dependencies. If mymodule1 depends
on foo#bar, it uses foo#bar and at the same time includes all the
dependencies of foo#bar, recursively. Similarly, mymodule1 overrides
any dependency of acme#myproject (acme#myproject is just meant as a
helper module to specify overrides in a single file, so its probably
not useful for any package to really depend on it) and additionally
includes all overrides from acme#myproject.
harry
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Wed, Feb 27, 2008 at 6:11 PM, Harald Braumann <ha...@unheit.net> wrote:
> On Wed, 27 Feb 2008 17:41:43 +0100
> "Xavier Hanin" <xa...@gmail.com> wrote:
>
> > On Wed, Feb 27, 2008 at 5:33 PM, Harald Braumann <ha...@unheit.net>
> > wrote:
> >
> > > On Wed, 27 Feb 2008 16:50:43 +0100
> > > "Xavier Hanin" <xa...@gmail.com> wrote:
> > >
> > > > BTW, I think that changing the dependency resolution algorithm in
> > > > a 2.0.xrelease is pretty strange. This can easily break builds,
> > > > which I wouldn't
> > > > suspect when upgrading on a 2.0.x stream.
> > > Well, you're not alone there.
> > >
> > > > > Maybe similar to a virtual module? It could then be specified by
> > > > > org/name/etc. just like dependencies.
> > > >
> > > > What do you mean by similar to a virtual module? Virtual module in
> > > > Ivy has a specific sense: it's a module which doesn't publish any
> > > > artifact. But maybe you're not referencing to this concept.
> > >
> > > I am. I just wanted to suggest that it shouldn't be a settings file
> > > but something like a module file.
> > >
> > > > Personnally I was just thinking about something very similar to
> > > > maven dependency management feature, with slight adaptation to
> > > > Ivy syntax.
> > > >
> > > > Something like:
> > > > <ivy-module version="2.0">
> > > > <info ... />
> > > > <dependencies>
> > > > </dependencies>
> > > > <dependencyManagement>
> > > > <dependency org="foo" name="bar" rev="1.0" />
> > > > </dependencyManagement>
> > > > </ivy-module>
> > >
> > > So in this case foo-bar-1.0 could actually be a virtual module, but
> > > as it is specified under dependencyManagement, it wouldn't pull in
> > > the dependencies but just override the versions.
> >
> > I'm not sure of what you mean. foo#bar is module, on which we suppose
> > the module defined with the ivy.xml define above depends indirectly.
> > Let's suppose we have foo#baz;2.0 -> foo#bar;1.0.1. With this ivy.xml:
> > <ivy-module version="2.0">
> > <info organisation="acme" name="mymodule" />
> > <dependencies>
> > <dependency org="foo" name="baz" rev="2.0" />
> > </dependencies>
> > <dependencyManagement>
> > <dependency org="foo" name="bar" rev="1.0" />
> > </dependencyManagement>
> > </ivy-module>
> >
> > Ivy would resolve the dependency closure as: { foo#baz;2.0 ,
> > foo#bar;1.0 } instead of { foo#baz;2.0 , foo#bar;1.0.1 }, because of
> > the dependencyManagement section. This is very similar to how Maven
> > handle this, right?
>
> Sorry, I misunderstood you before. You put the overrides in the ivy
> file directly. In this case you're right, of course. I thought of
> foo#bar more like the parent pom in maven nomenclature.
>
> In your proposal it would be nice, if dependencyManagement would be
> resolved recursively. This would help multi-module projects, where you
> want to define versions centrally in a single file. You could then
> specify a module without publications (thus I thought of a virtual
> module) and with only a dependencyMangement section. Like so:
>
> <ivy-module version="2.0">
> <info organisation="acme" name="myproject" />
> <dependencies>
> </dependencies>
> <dependencyManagement>
> <dependency org="foo" name="bar" rev="1.0" />
> <dependency org="foo" name="baz" rev="1.0" />
> </dependencyManagement>
> </ivy-module>
>
> <ivy-module version="2.0">
> <info organisation="acme" name="mymodule1" />
> <dependencies>
> ...
> </dependencies>
> <dependencyManagement>
> <dependency org="acme" name="myproject" rev="latest.integration" />
> </dependencyManagement>
> </ivy-module>
>
> <ivy-module version="2.0">
> <info organisation="acme" name="mymodule2" />
> <dependencies>
> ...
> </dependencies>
> <dependencyManagement>
> <dependency org="acme" name="myproject" rev="latest.integration" />
> </dependencyManagement>
> </ivy-module>
>
> And thus both, mymodule1 and mymodule2, would use the same versions of
> foo#bar and foo#baz.
I'm not sure to follow you. In acme#myproject, the dependencyManagement
section is used to override dependencies, ok. But then in acme#mymodule(1|2)
it's used (with the same syntax) as a kind of import or include mechanism,
right? How do we distinguish between the two?
Xavier
>
>
> harry
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Harald Braumann <ha...@unheit.net>.
On Wed, 27 Feb 2008 17:41:43 +0100
"Xavier Hanin" <xa...@gmail.com> wrote:
> On Wed, Feb 27, 2008 at 5:33 PM, Harald Braumann <ha...@unheit.net>
> wrote:
>
> > On Wed, 27 Feb 2008 16:50:43 +0100
> > "Xavier Hanin" <xa...@gmail.com> wrote:
> >
> > > BTW, I think that changing the dependency resolution algorithm in
> > > a 2.0.xrelease is pretty strange. This can easily break builds,
> > > which I wouldn't
> > > suspect when upgrading on a 2.0.x stream.
> > Well, you're not alone there.
> >
> > > > Maybe similar to a virtual module? It could then be specified by
> > > > org/name/etc. just like dependencies.
> > >
> > > What do you mean by similar to a virtual module? Virtual module in
> > > Ivy has a specific sense: it's a module which doesn't publish any
> > > artifact. But maybe you're not referencing to this concept.
> >
> > I am. I just wanted to suggest that it shouldn't be a settings file
> > but something like a module file.
> >
> > > Personnally I was just thinking about something very similar to
> > > maven dependency management feature, with slight adaptation to
> > > Ivy syntax.
> > >
> > > Something like:
> > > <ivy-module version="2.0">
> > > <info ... />
> > > <dependencies>
> > > </dependencies>
> > > <dependencyManagement>
> > > <dependency org="foo" name="bar" rev="1.0" />
> > > </dependencyManagement>
> > > </ivy-module>
> >
> > So in this case foo-bar-1.0 could actually be a virtual module, but
> > as it is specified under dependencyManagement, it wouldn't pull in
> > the dependencies but just override the versions.
>
> I'm not sure of what you mean. foo#bar is module, on which we suppose
> the module defined with the ivy.xml define above depends indirectly.
> Let's suppose we have foo#baz;2.0 -> foo#bar;1.0.1. With this ivy.xml:
> <ivy-module version="2.0">
> <info organisation="acme" name="mymodule" />
> <dependencies>
> <dependency org="foo" name="baz" rev="2.0" />
> </dependencies>
> <dependencyManagement>
> <dependency org="foo" name="bar" rev="1.0" />
> </dependencyManagement>
> </ivy-module>
>
> Ivy would resolve the dependency closure as: { foo#baz;2.0 ,
> foo#bar;1.0 } instead of { foo#baz;2.0 , foo#bar;1.0.1 }, because of
> the dependencyManagement section. This is very similar to how Maven
> handle this, right?
Sorry, I misunderstood you before. You put the overrides in the ivy
file directly. In this case you're right, of course. I thought of
foo#bar more like the parent pom in maven nomenclature.
In your proposal it would be nice, if dependencyManagement would be
resolved recursively. This would help multi-module projects, where you
want to define versions centrally in a single file. You could then
specify a module without publications (thus I thought of a virtual
module) and with only a dependencyMangement section. Like so:
<ivy-module version="2.0">
<info organisation="acme" name="myproject" />
<dependencies>
</dependencies>
<dependencyManagement>
<dependency org="foo" name="bar" rev="1.0" />
<dependency org="foo" name="baz" rev="1.0" />
</dependencyManagement>
</ivy-module>
<ivy-module version="2.0">
<info organisation="acme" name="mymodule1" />
<dependencies>
...
</dependencies>
<dependencyManagement>
<dependency org="acme" name="myproject" rev="latest.integration" />
</dependencyManagement>
</ivy-module>
<ivy-module version="2.0">
<info organisation="acme" name="mymodule2" />
<dependencies>
...
</dependencies>
<dependencyManagement>
<dependency org="acme" name="myproject" rev="latest.integration" />
</dependencyManagement>
</ivy-module>
And thus both, mymodule1 and mymodule2, would use the same versions of
foo#bar and foo#baz.
harry
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Wed, Feb 27, 2008 at 5:33 PM, Harald Braumann <ha...@unheit.net> wrote:
> On Wed, 27 Feb 2008 16:50:43 +0100
> "Xavier Hanin" <xa...@gmail.com> wrote:
>
> > BTW, I think that changing the dependency resolution algorithm in a
> > 2.0.xrelease is pretty strange. This can easily break builds, which I
> > wouldn't
> > suspect when upgrading on a 2.0.x stream.
> Well, you're not alone there.
>
> > > Maybe similar to a virtual module? It could then be specified by
> > > org/name/etc. just like dependencies.
> >
> > What do you mean by similar to a virtual module? Virtual module in
> > Ivy has a specific sense: it's a module which doesn't publish any
> > artifact. But maybe you're not referencing to this concept.
>
> I am. I just wanted to suggest that it shouldn't be a settings file but
> something like a module file.
>
> > Personnally I was just thinking about something very similar to maven
> > dependency management feature, with slight adaptation to Ivy syntax.
> >
> > Something like:
> > <ivy-module version="2.0">
> > <info ... />
> > <dependencies>
> > </dependencies>
> > <dependencyManagement>
> > <dependency org="foo" name="bar" rev="1.0" />
> > </dependencyManagement>
> > </ivy-module>
>
> So in this case foo-bar-1.0 could actually be a virtual module, but as
> it is specified under dependencyManagement, it wouldn't pull in the
> dependencies but just override the versions.
I'm not sure of what you mean. foo#bar is module, on which we suppose the
module defined with the ivy.xml define above depends indirectly. Let's
suppose we have foo#baz;2.0 -> foo#bar;1.0.1. With this ivy.xml:
<ivy-module version="2.0">
<info organisation="acme" name="mymodule" />
<dependencies>
<dependency org="foo" name="baz" rev="2.0" />
</dependencies>
<dependencyManagement>
<dependency org="foo" name="bar" rev="1.0" />
</dependencyManagement>
</ivy-module>
Ivy would resolve the dependency closure as: { foo#baz;2.0 , foo#bar;1.0 }
instead of { foo#baz;2.0 , foo#bar;1.0.1 }, because of the
dependencyManagement section. This is very similar to how Maven handle this,
right?
Xavier
>
> > Maybe we could allow to have wildcards in organization or module
> > names, using a matcher attribute to specify which matcher to use:
> > <dependencyManagement>
> > <dependency org="foo" name="bar-*" rev="1.0" matcher="glob" />
> > </dependencyManagement>
> >
> >
> > >
> > > > Could you open an issue about that?
> > >
> > > Of course I can also open an issue now so it won't be forgotten, if
> > > so desired.
> >
> > Opening the issue now does not require much understanding of Ivy
> > concepts. Since Ivy is supposed to be compatible with maven2, you can
> > first open a simple bug stating that Ivy does not support
> > dependencyManagement feature of maven2 with transitive dependencies.
> > Then later you (or somebody else) can open an issue about how we
> > could provide a similar feature in Ivy files, and link the two
> > issues.
>
> OK, will do.
>
> > Issues are editable, commentable and a very good way to track
> > what should/can be done. And when you open an issue, it's easier for
> > us to track that someone in the community asked for it, rather than
> > thinking it's something that comes out of the committer team. And
> > don't worry, you will never be culprit of anything, it's our "job" as
> > Ivy committers to make sure things are implemented with whole
> > consistency in mind. Well, it's what we try to do at least :-)
> >
> > Xavier
>
> harry
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Harald Braumann <ha...@unheit.net>.
On Wed, 27 Feb 2008 16:50:43 +0100
"Xavier Hanin" <xa...@gmail.com> wrote:
> BTW, I think that changing the dependency resolution algorithm in a
> 2.0.xrelease is pretty strange. This can easily break builds, which I
> wouldn't
> suspect when upgrading on a 2.0.x stream.
Well, you're not alone there.
> > Maybe similar to a virtual module? It could then be specified by
> > org/name/etc. just like dependencies.
>
> What do you mean by similar to a virtual module? Virtual module in
> Ivy has a specific sense: it's a module which doesn't publish any
> artifact. But maybe you're not referencing to this concept.
I am. I just wanted to suggest that it shouldn't be a settings file but
something like a module file.
> Personnally I was just thinking about something very similar to maven
> dependency management feature, with slight adaptation to Ivy syntax.
>
> Something like:
> <ivy-module version="2.0">
> <info ... />
> <dependencies>
> </dependencies>
> <dependencyManagement>
> <dependency org="foo" name="bar" rev="1.0" />
> </dependencyManagement>
> </ivy-module>
So in this case foo-bar-1.0 could actually be a virtual module, but as
it is specified under dependencyManagement, it wouldn't pull in the
dependencies but just override the versions.
> Maybe we could allow to have wildcards in organization or module
> names, using a matcher attribute to specify which matcher to use:
> <dependencyManagement>
> <dependency org="foo" name="bar-*" rev="1.0" matcher="glob" />
> </dependencyManagement>
>
>
> >
> > > Could you open an issue about that?
> >
> > Of course I can also open an issue now so it won't be forgotten, if
> > so desired.
>
> Opening the issue now does not require much understanding of Ivy
> concepts. Since Ivy is supposed to be compatible with maven2, you can
> first open a simple bug stating that Ivy does not support
> dependencyManagement feature of maven2 with transitive dependencies.
> Then later you (or somebody else) can open an issue about how we
> could provide a similar feature in Ivy files, and link the two
> issues.
OK, will do.
> Issues are editable, commentable and a very good way to track
> what should/can be done. And when you open an issue, it's easier for
> us to track that someone in the community asked for it, rather than
> thinking it's something that comes out of the committer team. And
> don't worry, you will never be culprit of anything, it's our "job" as
> Ivy committers to make sure things are implemented with whole
> consistency in mind. Well, it's what we try to do at least :-)
>
> Xavier
harry
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Wed, Feb 27, 2008 at 4:03 PM, Harald Braumann <ha...@unheit.net> wrote:
> On Wed, 27 Feb 2008 14:23:50 +0100
> "Xavier Hanin" <xa...@gmail.com> wrote:
>
> > On Wed, Feb 27, 2008 at 11:53 AM, Harald Braumann <ha...@unheit.net>
> > wrote:
> >
> > > On Wed, 27 Feb 2008 10:27:04 +0100
> > > "Xavier Hanin" <xa...@gmail.com> wrote:
> > >
> > > > On Tue, Feb 26, 2008 at 6:46 PM, Harald Braumann
> > > > <ha...@unheit.net> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > is it possible with ivy to specify the versions of dependencies
> > > > > separate from the actual dependency specification? Similar to
> > > > > the <dependencyMangement> section in maven's parent pom?
> > > >
> > > > There is no direct support for this currently in Ivy, what we
> > > > usually suggest is to use properties to specify the revisions,
> > > > and define these properties in a separate file. The result is
> > > > very similar to the dependency management feature.
> > >
> > > Fair enough, but like this I can only control direct dependencies.
> > > Maybe I should elaborate a bit more about what I want. Please note
> > > that I'm only familiar with Maven and only recently started to look
> > > into Ivy because I'm not completely satisfied with the former. So I
> > > might get the terminology wrong.
> > >
> > > Consider a project that is made up of multiple independent modules.
> > > Then there exists some uber-build, that has all the modules as
> > > dependencies and creates an installation package for the whole
> > > project.
> > >
> > > Many of the dependencies will be present in multiple modules, either
> > > directly or indirectly and very often with different versions. If I
> > > want to update some dependency, I don't want to go through all my
> > > modules and update there but I want to do it in a central place, for
> > > both direct and indirect dependencies.
> >
> > You can control indirect dependencies in conflict by using the
> > conflict management section of your ivy file. But this work only with
> > revisions in conflict. So there's currently no way in Ivy to override
> > the version of a dependency which is not in conflict and on which
> > your module does not depend. I didn't know that was possible with
> > maven2:
>
> The semantics of the dependencyManagement section was changed in
> 2.0.6 so that it can also override transitive dependencies [1].
That's probably why I wasn't aware of this.
>
> > the dependencyManagement documentation is not clear on this
> > subject.
>
> Well, documentation is one the points why I'm not really satisfied with
> Maven. But in this case I have to jump to maven's defence: "In addition,
> the version and scope of artifacts which are incorporated from
> transitive dependencies may also be controlled by specifying them in a
> dependency management section." [2]
You're right, this is clear enough. This documentation has been improved
since I last read it, this is a good point for maven users and for us too
(it helps to make Ivy compatible). I was refering to the documentation here:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
where the sentence "this allows project authors to directly specify the
versions of artifacts to be used when they are encountered in transitive
dependencies or in dependencies where no version has been specified" can be
interpreted in two ways depending if you consider that "where no version
has been specified" applies to direct dependencies only, or both transitive
and direct dependencies. But now I have a clear answer, both from the POM
reference doc and from experimentation.
BTW, I think that changing the dependency resolution algorithm in a
2.0.xrelease is pretty strange. This can easily break builds, which I
wouldn't
suspect when upgrading on a 2.0.x stream.
> > But now that I better see what is possible in maven, we can
> > consider that this is an incompatibility we have with maven2, and a
> > missing feature in terms of dependency management flexibility (no
> > alternative way to do it as I thought we had with properties). So we
> > should find a way to implement this for Ivy 2.0 final.
>
>
> Maybe similar to a virtual module? It could then be specified by
> org/name/etc. just like dependencies.
What do you mean by similar to a virtual module? Virtual module in Ivy has a
specific sense: it's a module which doesn't publish any artifact. But maybe
you're not referencing to this concept.
Personnally I was just thinking about something very similar to maven
dependency management feature, with slight adaptation to Ivy syntax.
Something like:
<ivy-module version="2.0">
<info ... />
<dependencies>
</dependencies>
<dependencyManagement>
<dependency org="foo" name="bar" rev="1.0" />
</dependencyManagement>
</ivy-module>
Maybe we could allow to have wildcards in organization or module names,
using a matcher attribute to specify which matcher to use:
<dependencyManagement>
<dependency org="foo" name="bar-*" rev="1.0" matcher="glob" />
</dependencyManagement>
>
> > Could you open an issue about that?
>
> Well, I could, but I'm not sure if I'm the right person to do so. As I
> said, I don't know ivy that well, yet, and so I might not be able to
> express myself properly. Also, what I've noticed about maven is, that
> someone said "hey, this would be a cool feature" and then it was
> implemented without having a broader concept behind. And so the way
> dependencies are resolved changed in subtle ways from version to
> version. I wouldn't want to be the culprit for this to happen in ivy.
>
> I'm currently in the process of setting up a project using ivy so in
> the course of the next view days I should get a better understanding of
> ivy's concepts. I will come back to this issue.
>
> Of course I can also open an issue now so it won't be forgotten, if so
> desired.
Opening the issue now does not require much understanding of Ivy concepts.
Since Ivy is supposed to be compatible with maven2, you can first open a
simple bug stating that Ivy does not support dependencyManagement feature of
maven2 with transitive dependencies. Then later you (or somebody else) can
open an issue about how we could provide a similar feature in Ivy files, and
link the two issues. Issues are editable, commentable and a very good way to
track what should/can be done. And when you open an issue, it's easier for
us to track that someone in the community asked for it, rather than thinking
it's something that comes out of the committer team. And don't worry, you
will never be culprit of anything, it's our "job" as Ivy committers to make
sure things are implemented with whole consistency in mind. Well, it's what
we try to do at least :-)
Xavier
>
> harry
>
> [1] http://jira.codehaus.org/browse/MNG-1577
> [2] http://maven.apache.org/pom.html#Dependency_Management
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Harald Braumann <ha...@unheit.net>.
On Wed, 27 Feb 2008 14:23:50 +0100
"Xavier Hanin" <xa...@gmail.com> wrote:
> On Wed, Feb 27, 2008 at 11:53 AM, Harald Braumann <ha...@unheit.net>
> wrote:
>
> > On Wed, 27 Feb 2008 10:27:04 +0100
> > "Xavier Hanin" <xa...@gmail.com> wrote:
> >
> > > On Tue, Feb 26, 2008 at 6:46 PM, Harald Braumann
> > > <ha...@unheit.net> wrote:
> > >
> > > > Hi,
> > > >
> > > > is it possible with ivy to specify the versions of dependencies
> > > > separate from the actual dependency specification? Similar to
> > > > the <dependencyMangement> section in maven's parent pom?
> > >
> > > There is no direct support for this currently in Ivy, what we
> > > usually suggest is to use properties to specify the revisions,
> > > and define these properties in a separate file. The result is
> > > very similar to the dependency management feature.
> >
> > Fair enough, but like this I can only control direct dependencies.
> > Maybe I should elaborate a bit more about what I want. Please note
> > that I'm only familiar with Maven and only recently started to look
> > into Ivy because I'm not completely satisfied with the former. So I
> > might get the terminology wrong.
> >
> > Consider a project that is made up of multiple independent modules.
> > Then there exists some uber-build, that has all the modules as
> > dependencies and creates an installation package for the whole
> > project.
> >
> > Many of the dependencies will be present in multiple modules, either
> > directly or indirectly and very often with different versions. If I
> > want to update some dependency, I don't want to go through all my
> > modules and update there but I want to do it in a central place, for
> > both direct and indirect dependencies.
>
> You can control indirect dependencies in conflict by using the
> conflict management section of your ivy file. But this work only with
> revisions in conflict. So there's currently no way in Ivy to override
> the version of a dependency which is not in conflict and on which
> your module does not depend. I didn't know that was possible with
> maven2:
The semantics of the dependencyManagement section was changed in
2.0.6 so that it can also override transitive dependencies [1].
> the dependencyManagement documentation is not clear on this
> subject.
Well, documentation is one the points why I'm not really satisfied with
Maven. But in this case I have to jump to maven's defence: "In addition,
the version and scope of artifacts which are incorporated from
transitive dependencies may also be controlled by specifying them in a
dependency management section." [2]
> But now that I better see what is possible in maven, we can
> consider that this is an incompatibility we have with maven2, and a
> missing feature in terms of dependency management flexibility (no
> alternative way to do it as I thought we had with properties). So we
> should find a way to implement this for Ivy 2.0 final.
Maybe similar to a virtual module? It could then be specified by
org/name/etc. just like dependencies.
> Could you open an issue about that?
Well, I could, but I'm not sure if I'm the right person to do so. As I
said, I don't know ivy that well, yet, and so I might not be able to
express myself properly. Also, what I've noticed about maven is, that
someone said "hey, this would be a cool feature" and then it was
implemented without having a broader concept behind. And so the way
dependencies are resolved changed in subtle ways from version to
version. I wouldn't want to be the culprit for this to happen in ivy.
I'm currently in the process of setting up a project using ivy so in
the course of the next view days I should get a better understanding of
ivy's concepts. I will come back to this issue.
Of course I can also open an issue now so it won't be forgotten, if so
desired.
harry
[1] http://jira.codehaus.org/browse/MNG-1577
[2] http://maven.apache.org/pom.html#Dependency_Management
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Wed, Feb 27, 2008 at 11:53 AM, Harald Braumann <ha...@unheit.net> wrote:
> On Wed, 27 Feb 2008 10:27:04 +0100
> "Xavier Hanin" <xa...@gmail.com> wrote:
>
> > On Tue, Feb 26, 2008 at 6:46 PM, Harald Braumann <ha...@unheit.net>
> > wrote:
> >
> > > Hi,
> > >
> > > is it possible with ivy to specify the versions of dependencies
> > > separate from the actual dependency specification? Similar to the
> > > <dependencyMangement> section in maven's parent pom?
> >
> > There is no direct support for this currently in Ivy, what we usually
> > suggest is to use properties to specify the revisions, and define
> > these properties in a separate file. The result is very similar to
> > the dependency management feature.
>
> Fair enough, but like this I can only control direct dependencies.
> Maybe I should elaborate a bit more about what I want. Please note
> that I'm only familiar with Maven and only recently started to look
> into Ivy because I'm not completely satisfied with the former. So I
> might get the terminology wrong.
>
> Consider a project that is made up of multiple independent modules.
> Then there exists some uber-build, that has all the modules as
> dependencies and creates an installation package for the whole project.
>
> Many of the dependencies will be present in multiple modules, either
> directly or indirectly and very often with different versions. If I
> want to update some dependency, I don't want to go through all my
> modules and update there but I want to do it in a central place, for
> both direct and indirect dependencies.
You can control indirect dependencies in conflict by using the conflict
management section of your ivy file. But this work only with revisions in
conflict. So there's currently no way in Ivy to override the version of a
dependency which is not in conflict and on which your module does not
depend. I didn't know that was possible with maven2: the
dependencyManagement documentation is not clear on this subject. But now
that I better see what is possible in maven, we can consider that this is an
incompatibility we have with maven2, and a missing feature in terms of
dependency management flexibility (no alternative way to do it as I thought
we had with properties). So we should find a way to implement this for Ivy
2.0 final.
Could you open an issue about that?
Xavier
>
>
> The only solution I see so far is to use a separate repository for the
> project. But then I'd have to copy the stuff in there manually from
> other repositories. Certainly doable, but not as nice as just
> specifying the versions in a file or some such. Compare this to the
> Debian repository, where you have one pool with all packages and files
> that specify the actual versions that go into a release (stable,
> unstable, sid, experimental). It's kind of a partitioning of a central
> repository.
>
> Please note that this problem also exists for single modules. Lets say
> I have to dependencies, that both depend on foo. Now I update one
> dependency, the new version of which depends on a new version of foo.
> But I don't want to update foo if it's not necessary. Again I would
> like to be able to specify the versions in a single place.
>
> I would be quite surprised if others didn't have the same problems
> with randomly changing versions of indirect dependencies.
>
> Regards,
> harry
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Wed, Feb 27, 2008 at 5:50 PM, Scott Oster <os...@bmi.osu.edu> wrote:
> Maybe I'm not seeing the whole picture, but I think this could be
> supported in Ivy today (although maybe not as cleanly as you like).
> Could you not just make use of the conflict management system (as
> previously suggested), by implementing a resolution scheme that took the
> "nearest" version in the dependency graph. That is, If A depends on B
> and C and B depends on C, you take A's version of C even if it is older
> than Bs (as A's version of C is a shorter path through the dependency
> graph than B's is).
>
> The issue you mentioned before with this approach is that there is
> potentially no conflict if you just want to specify a hard version of
> transitive dependencies, even if there is no conflict. I think the way
> around this is you simple introduce a dependency on the module you want
> to override (thus introducing a conflict). This is a bit of a leaky
> abstraction, as your module doesn't directly need this module (just
> through transitivity), but I don't see it as a huge issue as to specify
> that you require a specific version of a module which you don't directly
> depend on, implies to me that you have already leaked that abstraction
> (i.e you already know you need it, and want to control the version).
>
> That being said, I would support this being more straight-forwardly
> controllable; it's something I looked for when I moved to Ivy. In terms
> of organization would suggest some new dependencyManagement
> configuration section should be introduced with contains this
> information, as well as the conflict management section as the two are
> related,
I agree, but I wonder what syntax to use. Do you have any idea?
> and you would need to specify the semantics of which overrides
> the other when your conflict management information is in conflict with
> your specific version constraints. :)
As soon as you specify the dependencyManagement, you override the version
constraint from all dependers, and thus there's no possible conflict. Hence
I think dependencyManagement should take priority over conflict management.
Xavier
>
>
> Scott
>
> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: Wednesday, February 27, 2008 9:17 AM
> To: ivy-user@ant.apache.org
> Subject: Re: specify versions separate from dependencies
>
> If you update your central properties file each time you publish a new
> version, and keep using unexpanded properties for revisions in published
> ivy
> files, it becomes very similar to using latest.integration versions in
> your
> published files :-) Except that you can override properties before
> loading
> the central properties file.
>
> But after trying out how the dependencyManagement feature of maven
> actually
> works, I think we really need to implement something similar in Ivy. The
> dependencyManagement feature let you override the revision of any
> dependency, including transitive ones, and this can be useful. This is
> really in the spirit of flexibility and control over dependencies that I
> usually like with Ivy, and on this I think we have to admit that Maven
> beats
> Ivy. So I think we should provide a similar feature, as easy to use as
> maven's one.
>
> Xavier
>
> On Wed, Feb 27, 2008 at 2:32 PM, John Gill <ll...@gmail.com> wrote:
>
> > Sorry if this isn't on the right track of what you are asking, and I
> am
> > not
> > sure I like what I am about to suggest!
> >
> > As Xavier stated you can put the revisions of the dependencies in a
> > properties file, and I guess there is no reason why you couldn't have
> one
> > big properties file with all the revisions in it (which you would have
> to
> > maintain somehow which is the bit I don't really like), and then in
> your
> > ivy.xml file you can reference the properties that you are actually
> using.
> >
> > Maybe, what you could also do is use a post-publish-artifact trigger
> (it
> > would be better if there was a post-publish trigger rather than one
> for
> > each
> > artifact) to update the central properties file when the new revision
> when
> > it is published. It might also be possible to have different
> properties
> > files for different resolvers for the different releases (unstable,
> sid,
> > experimental). The trigger informs you of the resolver used which
> would
> > tell
> > you which properties file to update using
> >
> > Is this a good idea? A part of me finds it this idea appealing, but I
> am
> > not
> > convinced it's a good idea. My main problem is that the builds would
> not
> > be
> > totally reproducible, as the central revisions.properties file would
> not
> > be
> > under version control.
> >
> > On the other hand, maybe I missed the point entirely.
> >
> >
> > On Wed, Feb 27, 2008 at 7:53 PM, Harald Braumann <ha...@unheit.net>
> wrote:
> >
> > > On Wed, 27 Feb 2008 10:27:04 +0100
> > > "Xavier Hanin" <xa...@gmail.com> wrote:
> > >
> > > > On Tue, Feb 26, 2008 at 6:46 PM, Harald Braumann
> <ha...@unheit.net>
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > is it possible with ivy to specify the versions of dependencies
> > > > > separate from the actual dependency specification? Similar to
> the
> > > > > <dependencyMangement> section in maven's parent pom?
> > > >
> > > > There is no direct support for this currently in Ivy, what we
> usually
> > > > suggest is to use properties to specify the revisions, and define
> > > > these properties in a separate file. The result is very similar to
> > > > the dependency management feature.
> > >
> > > Fair enough, but like this I can only control direct dependencies.
> > > Maybe I should elaborate a bit more about what I want. Please note
> > > that I'm only familiar with Maven and only recently started to look
> > > into Ivy because I'm not completely satisfied with the former. So I
> > > might get the terminology wrong.
> > >
> > > Consider a project that is made up of multiple independent modules.
> > > Then there exists some uber-build, that has all the modules as
> > > dependencies and creates an installation package for the whole
> project.
> > >
> > > Many of the dependencies will be present in multiple modules, either
> > > directly or indirectly and very often with different versions. If I
> > > want to update some dependency, I don't want to go through all my
> > > modules and update there but I want to do it in a central place, for
> > > both direct and indirect dependencies.
> > >
> > > The only solution I see so far is to use a separate repository for
> the
> > > project. But then I'd have to copy the stuff in there manually from
> > > other repositories. Certainly doable, but not as nice as just
> > > specifying the versions in a file or some such. Compare this to the
> > > Debian repository, where you have one pool with all packages and
> files
> > > that specify the actual versions that go into a release (stable,
> > > unstable, sid, experimental). It's kind of a partitioning of a
> central
> > > repository.
> > >
> > > Please note that this problem also exists for single modules. Lets
> say
> > > I have to dependencies, that both depend on foo. Now I update one
> > > dependency, the new version of which depends on a new version of
> foo.
> > > But I don't want to update foo if it's not necessary. Again I would
> > > like to be able to specify the versions in a single place.
> > >
> > > I would be quite surprised if others didn't have the same problems
> > > with randomly changing versions of indirect dependencies.
> > >
> > > Regards,
> > > harry
> > >
> >
> >
> >
> > --
> > Regards,
> > John Gill
> >
>
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Harald Braumann <ha...@unheit.net>.
On Wed, 27 Feb 2008 13:25:01 -0500
"Scott Oster" <os...@bmi.osu.edu> wrote:
> Point taken on the desire to not use the work around; I was just
> suggesting it as an, albeit suboptimal, way to work with the support
> that is there today.
>
> On your second point about writing a tool to automatically specify the
> versions, I'm not sure I really see the point of using a system like
> Ivy if you want to "hard specify" every single version of all your
> dependencies.
First of all, I can use all of ivy's power to create
that versions file. A task that is really hard to do manually. The
dependency resolution is just moved from each ant invocation to a
specific "integrate a new dependency" step. Also I can have a central
repository to share the work and there is meta-data attached to the
modules, which I would lose if I just copy libraries in a local lib/
directory.
> If you don't do "all" of them, you are left with the
> same potential need for automatic conflict resolution, as some new
> version of a module may introduce a new conflict, which you don't
> have a hard specified rule.
I would never do automatic conflict resolution. A conflict has to lead
to a build error, in which case I would resolve the conflict manually.
I can do this with the conflicts/manager section, but, as posted in
another mail, I would like to have support for multi-module projects.
> Therefore, I think what is needed is the ability to provide Ivy with
> mediation/arbitration rules which are consulted at the time when
> decisions are being made on which versions to use for transitive
> dependencies. Currently Ivy supports plugging in logic to the
> decision only when there is a conflict; what is missing is just a way
> to plug in logic when there aren't conflicts. I think a new section
> in the Ivy file which contains the current "conflicts" section, and a
> new "versioncontraints" section would suffice.
Fair enough. whatever best fits the ivy philosophy.
> I agree with other
> posts "dependencyManagement" is a poor and confusing name for such a
> section, but don't really have many better suggestions, but feel the
> name should be derived from the fact that it's a place to provide
> rules to the engine when processing transitive dependencies. A
> "manager" syntax similar to "conflicts" would probably suffice. You
> could then implement your own versioncontraints manager to read a
> "versions file" if you liked; others could simply hard-code the
> versions they want for specific transitive dependencies.
>
> Scott
>
RE: specify versions separate from dependencies
Posted by Scott Oster <os...@bmi.osu.edu>.
Point taken on the desire to not use the work around; I was just
suggesting it as an, albeit suboptimal, way to work with the support
that is there today.
On your second point about writing a tool to automatically specify the
versions, I'm not sure I really see the point of using a system like Ivy
if you want to "hard specify" every single version of all your
dependencies. If you don't do "all" of them, you are left with the same
potential need for automatic conflict resolution, as some new version of
a module may introduce a new conflict, which you don't have a hard
specified rule.
Therefore, I think what is needed is the ability to provide Ivy with
mediation/arbitration rules which are consulted at the time when
decisions are being made on which versions to use for transitive
dependencies. Currently Ivy supports plugging in logic to the decision
only when there is a conflict; what is missing is just a way to plug in
logic when there aren't conflicts. I think a new section in the Ivy
file which contains the current "conflicts" section, and a new
"versioncontraints" section would suffice. I agree with other posts
"dependencyManagement" is a poor and confusing name for such a section,
but don't really have many better suggestions, but feel the name should
be derived from the fact that it's a place to provide rules to the
engine when processing transitive dependencies. A "manager" syntax
similar to "conflicts" would probably suffice. You could then implement
your own versioncontraints manager to read a "versions file" if you
liked; others could simply hard-code the versions they want for specific
transitive dependencies.
Scott
-----Original Message-----
From: Harald Braumann [mailto:harry@unheit.net]
Sent: Wednesday, February 27, 2008 12:36 PM
To: ivy-user@ant.apache.org
Subject: Re: specify versions separate from dependencies
On Wed, 27 Feb 2008 11:50:11 -0500
"Scott Oster" <os...@bmi.osu.edu> wrote:
> Maybe I'm not seeing the whole picture, but I think this could be
> supported in Ivy today (although maybe not as cleanly as you like).
> Could you not just make use of the conflict management system (as
> previously suggested), by implementing a resolution scheme that took
> the "nearest" version in the dependency graph. That is, If A depends
> on B and C and B depends on C, you take A's version of C even if it is
> older than Bs (as A's version of C is a shorter path through the
> dependency graph than B's is).
No, believe me, it only leads to tears. We used nearest with maven for
our project. This project is quite big and contains a lot of
dependencies. The problem is now, that there are multiple roots, because
its a multi-module project. So nearest really depends on where you
start. In addition there is the uber-build, that takes all the modules
and creates the installation package. Now if you change a dependency
anywhere, it's completely unpredictable which indirect dependencies
change. And not only in one place, but in multiple places.
Even worse, until recently maven selected the dependency at random, if
there where conflicting dependencies at the same distance. They have
fixed this by ordering them alphabetically, so now, at least, its
deterministic. But this doesn't help you either, because whether your
software runs or not doesn't really depend on alphabetic ordering of
dependencies. Also using latest doesn't help, because again, that's no
criterion for whether your software runs or not. Thus I want to be able
to control the versions in a single place in some deterministic and,
more importantly, graspable way.
> The issue you mentioned before with this approach is that there is
> potentially no conflict if you just want to specify a hard version of
> transitive dependencies, even if there is no conflict. I think the
> way around this is you simple introduce a dependency on the module you
> want to override (thus introducing a conflict). This is a bit of a
> leaky abstraction, as your module doesn't directly need this module
> (just through transitivity), but I don't see it as a huge issue as to
> specify that you require a specific version of a module which you
> don't directly depend on, implies to me that you have already leaked
> that abstraction (i.e you already know you need it, and want to
> control the version).
Adds more woe than relieve. Firstly, you have to do it in multiple
places (see above) and it is guaranteed that you will forget it
somewhere and have subtle inconsistencies. Secondly, every time you
change a dependency you have to walk through all your overrides and
check if they still apply.
>From the many, many hours of experience I have in fixing dependency
problems, I can tell you that for any reasonable complex project,
automatic conflict resolution does not work and leads to a lot of
problems and headache. Thus I want to be in control of the versions.
Once this is supported by ivy, my plan is to create a tool that creates
the versions file for you. It would resolve all the dependencies
recursively and write the versions file. It would also tell you all
conflict, which you have to resolve by hand (IMHO the only sensible
thing to do). If you change any dependency, you re-run the tool and it
tells you all the new conflicts (by comparing with the old version of
the versions file).
harry
>
> That being said, I would support this being more straight-forwardly
> controllable; it's something I looked for when I moved to Ivy. In
> terms of organization would suggest some new dependencyManagement
> configuration section should be introduced with contains this
> information, as well as the conflict management section as the two are
> related, and you would need to specify the semantics of which
> overrides the other when your conflict management information is in
> conflict with your specific version constraints. :)
>
> Scott
>
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Wed, Feb 27, 2008 at 7:57 PM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:
> I like this whole discussion with the ability to more closely specify
> transitive dependencies. However, I would add one more requirement. I
> think this control should also be allowed to be specified in the <modules>
> section of the settings file. This is very important when you are in charge
> of an entire company's modules each with their own release schedules and
> combination of modules and branches. I could spend my time writing settings
> files for each product release with complete control over what branch of
> what modules and even what explicit revisions should be used. Then a given
> developer working on a given product release would simply set an environment
> variable or something to control which settings file to use. Then he
> automatically gets the blessed configuration for that product release. I
> don't want to have to go to each ivy file and make changes all over the
> place which could easily result in branching each module's source code just
> to get a new ivy.xml file.
>
> This concept is very similar to Clearcase's config spec idea, except I
> call it an Ivy Release Spec.
If we provide both an include mechanism and the "dependency-constraint"
section, you can simply make sure that all your ivy files have an include
like that:
<include file="${ivy.general.include.file}" />
Then you can easily control which file is actually included by setting a
property in your settings. The advantage of this compared to using the
settings file itself to define the version contraints is that during deliver
we would merge the included file (as we do for configurations file
inclusion), so that everything ends up in a self contained file in the
repository. Indeed I find rather dangerous to be able in the settings file
to fully bypass the dependency versions expressed in the ivy files. You
resolve your dependencies with one settings, then publish your file, then
someone else add a dependency on your module with different settings and get
a fully different dependency closure. So IMO file inclusion is a better
approach. Is this sensible?
Xavier
>
>
> ---
> Shawn Castrianni
>
>
> -----Original Message-----
> From: Harald Braumann [mailto:harry@unheit.net]
> Sent: Wednesday, February 27, 2008 12:50 PM
> To: ivy-user@ant.apache.org
> Subject: Re: specify versions separate from dependencies
>
> On Wed, 27 Feb 2008 19:02:57 +0100
> "Xavier Hanin" <xa...@gmail.com> wrote:
>
> > On Wed, Feb 27, 2008 at 6:35 PM, Harald Braumann <ha...@unheit.net>
> > wrote:
> >
> > > From the many, many hours of experience I have in fixing dependency
> > > problems, I can tell you that for any reasonable complex project,
> > > automatic conflict resolution does not work and leads to a lot of
> > > problems and headache. Thus I want to be in control of the versions.
> > > Once this is supported by ivy, my plan is to create a tool that
> > > creates the versions file for you. It would resolve all the
> > > dependencies recursively and write the versions file. It would also
> > > tell you all conflict, which you have to resolve by hand (IMHO the
> > > only sensible thing to do). If you change any dependency, you re-run
> > > the tool and it tells you all the new conflicts (by comparing with
> > > the old version of the versions file).
> >
> > Interesting idea. Note that if you need overriding only when you have
> > conflicts, the conflicts/manager elements in Ivy files can already fit
> > your needs AFAIU: you run a resolve with a conflict manager which only
> > collects conflicts from your tool, then ask the user to select
> > versions, and create the conflict management section to include in
> > your main ivy file. Since inclusion is not (yet?) supported, you still
> > need to do some kind of automatic merging before giving this to Ivy,
> > but this is not the hardest part. The end result would be really close
> > to what you would have with a dependency override mechanism, except
> > that conflicts would still appear as conflicts in dependency reports.
> > WDYT?
>
> That would solve the problem of overriding conflicts. But in addition I
> would like to be able to specify versions to use for multiple modules in a
> single place.
>
> Modularising a project has a couple of advantages. But it also adds
> complexity, which makes modularisation kind of a PITA.
>
> Our project, and also some open source projects I follow, which went the
> stony path of modularisation (see e.g. X.org) put a lot of effort into
> custom tools just to make the building and installation somehow manageable.
> And still they have problems constantly.
>
> Now I think that it doesn't have to be like this. The pain could be
> alleviated by proper tool support and a dependency management system seems
> to be the perfect match.
>
> harry
>
> ----------------------------------------------------------------------
> This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient. Any
> review, use, distribution, or disclosure by others is strictly prohibited.
> If you are not the intended recipient (or authorized to receive information
> for the intended recipient), please contact the sender by reply e-mail and
> delete all copies of this message.
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Harald Braumann <ha...@unheit.net>.
On Wed, 27 Feb 2008 12:57:04 -0600
Shawn Castrianni <Sh...@halliburton.com> wrote:
> I like this whole discussion with the ability to more closely specify
> transitive dependencies. However, I would add one more requirement.
> I think this control should also be allowed to be specified in the
> <modules> section of the settings file. This is very important when
> you are in charge of an entire company's modules each with their own
> release schedules and combination of modules and branches. I could
> spend my time writing settings files for each product release with
> complete control over what branch of what modules and even what
> explicit revisions should be used. Then a given developer working on
> a given product release would simply set an environment variable or
> something to control which settings file to use. Then he
> automatically gets the blessed configuration for that product
> release. I don't want to have to go to each ivy file and make
> changes all over the place which could easily result in branching
> each module's source code just to get a new ivy.xml file.
>
Good point. I was just thinking about something along these lines.
> This concept is very similar to Clearcase's config spec idea, except
> I call it an Ivy Release Spec.
>
> ---
> Shawn Castrianni
harry
RE: specify versions separate from dependencies
Posted by Shawn Castrianni <Sh...@halliburton.com>.
I like this whole discussion with the ability to more closely specify transitive dependencies. However, I would add one more requirement. I think this control should also be allowed to be specified in the <modules> section of the settings file. This is very important when you are in charge of an entire company's modules each with their own release schedules and combination of modules and branches. I could spend my time writing settings files for each product release with complete control over what branch of what modules and even what explicit revisions should be used. Then a given developer working on a given product release would simply set an environment variable or something to control which settings file to use. Then he automatically gets the blessed configuration for that product release. I don't want to have to go to each ivy file and make changes all over the place which could easily result in branching each module's source code just to get a new ivy.xml file.
This concept is very similar to Clearcase's config spec idea, except I call it an Ivy Release Spec.
---
Shawn Castrianni
-----Original Message-----
From: Harald Braumann [mailto:harry@unheit.net]
Sent: Wednesday, February 27, 2008 12:50 PM
To: ivy-user@ant.apache.org
Subject: Re: specify versions separate from dependencies
On Wed, 27 Feb 2008 19:02:57 +0100
"Xavier Hanin" <xa...@gmail.com> wrote:
> On Wed, Feb 27, 2008 at 6:35 PM, Harald Braumann <ha...@unheit.net>
> wrote:
>
> > From the many, many hours of experience I have in fixing dependency
> > problems, I can tell you that for any reasonable complex project,
> > automatic conflict resolution does not work and leads to a lot of
> > problems and headache. Thus I want to be in control of the versions.
> > Once this is supported by ivy, my plan is to create a tool that
> > creates the versions file for you. It would resolve all the
> > dependencies recursively and write the versions file. It would also
> > tell you all conflict, which you have to resolve by hand (IMHO the
> > only sensible thing to do). If you change any dependency, you re-run
> > the tool and it tells you all the new conflicts (by comparing with
> > the old version of the versions file).
>
> Interesting idea. Note that if you need overriding only when you have
> conflicts, the conflicts/manager elements in Ivy files can already fit
> your needs AFAIU: you run a resolve with a conflict manager which only
> collects conflicts from your tool, then ask the user to select
> versions, and create the conflict management section to include in
> your main ivy file. Since inclusion is not (yet?) supported, you still
> need to do some kind of automatic merging before giving this to Ivy,
> but this is not the hardest part. The end result would be really close
> to what you would have with a dependency override mechanism, except
> that conflicts would still appear as conflicts in dependency reports.
> WDYT?
That would solve the problem of overriding conflicts. But in addition I would like to be able to specify versions to use for multiple modules in a single place.
Modularising a project has a couple of advantages. But it also adds complexity, which makes modularisation kind of a PITA.
Our project, and also some open source projects I follow, which went the stony path of modularisation (see e.g. X.org) put a lot of effort into custom tools just to make the building and installation somehow manageable. And still they have problems constantly.
Now I think that it doesn't have to be like this. The pain could be alleviated by proper tool support and a dependency management system seems to be the perfect match.
harry
----------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
Re: specify versions separate from dependencies
Posted by Harald Braumann <ha...@unheit.net>.
On Wed, 27 Feb 2008 19:02:57 +0100
"Xavier Hanin" <xa...@gmail.com> wrote:
> On Wed, Feb 27, 2008 at 6:35 PM, Harald Braumann <ha...@unheit.net>
> wrote:
>
> > From the many, many hours of experience I have in fixing dependency
> > problems, I can tell you that for any reasonable complex
> > project, automatic conflict resolution does not work and leads to a
> > lot of problems and headache. Thus I want to be in control of the
> > versions. Once this is supported by ivy, my plan is to create a
> > tool that creates the versions file for you. It would resolve all
> > the dependencies recursively and write the versions file. It would
> > also tell you all conflict, which you have to resolve by hand (IMHO
> > the only sensible thing to do). If you change any dependency, you
> > re-run the tool and it tells you all the new conflicts (by
> > comparing with the old version of the versions file).
>
> Interesting idea. Note that if you need overriding only when you have
> conflicts, the conflicts/manager elements in Ivy files can already
> fit your needs AFAIU: you run a resolve with a conflict manager which
> only collects conflicts from your tool, then ask the user to select
> versions, and create the conflict management section to include in
> your main ivy file. Since inclusion is not (yet?) supported, you
> still need to do some kind of automatic merging before giving this to
> Ivy, but this is not the hardest part. The end result would be really
> close to what you would have with a dependency override mechanism,
> except that conflicts would still appear as conflicts in dependency
> reports. WDYT?
That would solve the problem of overriding conflicts. But in addition I
would like to be able to specify versions to use for multiple modules
in a single place.
Modularising a project has a couple of advantages. But it also adds
complexity, which makes modularisation kind of a PITA.
Our project, and also some open source projects I follow, which went
the stony path of modularisation (see e.g. X.org) put a lot of effort
into custom tools just to make the building and installation somehow
manageable. And still they have problems constantly.
Now I think that it doesn't have to be like this. The pain could
be alleviated by proper tool support and a dependency management system
seems to be the perfect match.
harry
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Wed, Feb 27, 2008 at 6:35 PM, Harald Braumann <ha...@unheit.net> wrote:
> On Wed, 27 Feb 2008 11:50:11 -0500
> "Scott Oster" <os...@bmi.osu.edu> wrote:
>
> > Maybe I'm not seeing the whole picture, but I think this could be
> > supported in Ivy today (although maybe not as cleanly as you like).
> > Could you not just make use of the conflict management system (as
> > previously suggested), by implementing a resolution scheme that took
> > the "nearest" version in the dependency graph. That is, If A depends
> > on B and C and B depends on C, you take A's version of C even if it
> > is older than Bs (as A's version of C is a shorter path through the
> > dependency graph than B's is).
>
> No, believe me, it only leads to tears. We used nearest with maven for
> our project. This project is quite big and contains a lot of
> dependencies. The problem is now, that there are multiple roots,
> because its a multi-module project. So nearest really depends on where
> you start. In addition there is the uber-build, that takes all the
> modules and creates the installation package. Now if you change a
> dependency anywhere, it's completely unpredictable which indirect
> dependencies change. And not only in one place, but in multiple places.
> Even worse, until recently maven selected the dependency at random, if
> there where conflicting dependencies at the same distance. They have
> fixed this by ordering them alphabetically, so now, at least, its
> deterministic. But this doesn't help you either, because whether your
> software runs or not doesn't really depend on alphabetic ordering of
> dependencies. Also using latest doesn't help, because again, that's no
> criterion for whether your software runs or not. Thus I want to be able
> to control the versions in a single place in some deterministic and,
> more importantly, graspable way.
>
> > The issue you mentioned before with this approach is that there is
> > potentially no conflict if you just want to specify a hard version of
> > transitive dependencies, even if there is no conflict. I think the
> > way around this is you simple introduce a dependency on the module
> > you want to override (thus introducing a conflict). This is a bit of
> > a leaky abstraction, as your module doesn't directly need this module
> > (just through transitivity), but I don't see it as a huge issue as to
> > specify that you require a specific version of a module which you
> > don't directly depend on, implies to me that you have already leaked
> > that abstraction (i.e you already know you need it, and want to
> > control the version).
>
> Adds more woe than relieve. Firstly, you have to do it in multiple
> places (see above) and it is guaranteed that you will forget it
> somewhere and have subtle inconsistencies. Secondly, every time you
> change a dependency you have to walk through all your overrides and
> check if they still apply.
>
> From the many, many hours of experience I have in fixing dependency
> problems, I can tell you that for any reasonable complex
> project, automatic conflict resolution does not work and leads to a lot
> of problems and headache. Thus I want to be in control of the versions.
> Once this is supported by ivy, my plan is to create a tool that creates
> the versions file for you. It would resolve all the dependencies
> recursively and write the versions file. It would also tell you all
> conflict, which you have to resolve by hand (IMHO the only sensible
> thing to do). If you change any dependency, you re-run the tool and it
> tells you all the new conflicts (by comparing with the old version of
> the versions file).
Interesting idea. Note that if you need overriding only when you have
conflicts, the conflicts/manager elements in Ivy files can already fit your
needs AFAIU: you run a resolve with a conflict manager which only collects
conflicts from your tool, then ask the user to select versions, and create
the conflict management section to include in your main ivy file. Since
inclusion is not (yet?) supported, you still need to do some kind of
automatic merging before giving this to Ivy, but this is not the hardest
part. The end result would be really close to what you would have with a
dependency override mechanism, except that conflicts would still appear as
conflicts in dependency reports. WDYT?
Xavier
>
>
> harry
>
> >
> > That being said, I would support this being more straight-forwardly
> > controllable; it's something I looked for when I moved to Ivy. In
> > terms of organization would suggest some new dependencyManagement
> > configuration section should be introduced with contains this
> > information, as well as the conflict management section as the two are
> > related, and you would need to specify the semantics of which
> > overrides the other when your conflict management information is in
> > conflict with your specific version constraints. :)
> >
> > Scott
> >
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by Harald Braumann <ha...@unheit.net>.
On Wed, 27 Feb 2008 11:50:11 -0500
"Scott Oster" <os...@bmi.osu.edu> wrote:
> Maybe I'm not seeing the whole picture, but I think this could be
> supported in Ivy today (although maybe not as cleanly as you like).
> Could you not just make use of the conflict management system (as
> previously suggested), by implementing a resolution scheme that took
> the "nearest" version in the dependency graph. That is, If A depends
> on B and C and B depends on C, you take A's version of C even if it
> is older than Bs (as A's version of C is a shorter path through the
> dependency graph than B's is).
No, believe me, it only leads to tears. We used nearest with maven for
our project. This project is quite big and contains a lot of
dependencies. The problem is now, that there are multiple roots,
because its a multi-module project. So nearest really depends on where
you start. In addition there is the uber-build, that takes all the
modules and creates the installation package. Now if you change a
dependency anywhere, it's completely unpredictable which indirect
dependencies change. And not only in one place, but in multiple places.
Even worse, until recently maven selected the dependency at random, if
there where conflicting dependencies at the same distance. They have
fixed this by ordering them alphabetically, so now, at least, its
deterministic. But this doesn't help you either, because whether your
software runs or not doesn't really depend on alphabetic ordering of
dependencies. Also using latest doesn't help, because again, that's no
criterion for whether your software runs or not. Thus I want to be able
to control the versions in a single place in some deterministic and,
more importantly, graspable way.
> The issue you mentioned before with this approach is that there is
> potentially no conflict if you just want to specify a hard version of
> transitive dependencies, even if there is no conflict. I think the
> way around this is you simple introduce a dependency on the module
> you want to override (thus introducing a conflict). This is a bit of
> a leaky abstraction, as your module doesn't directly need this module
> (just through transitivity), but I don't see it as a huge issue as to
> specify that you require a specific version of a module which you
> don't directly depend on, implies to me that you have already leaked
> that abstraction (i.e you already know you need it, and want to
> control the version).
Adds more woe than relieve. Firstly, you have to do it in multiple
places (see above) and it is guaranteed that you will forget it
somewhere and have subtle inconsistencies. Secondly, every time you
change a dependency you have to walk through all your overrides and
check if they still apply.
From the many, many hours of experience I have in fixing dependency
problems, I can tell you that for any reasonable complex
project, automatic conflict resolution does not work and leads to a lot
of problems and headache. Thus I want to be in control of the versions.
Once this is supported by ivy, my plan is to create a tool that creates
the versions file for you. It would resolve all the dependencies
recursively and write the versions file. It would also tell you all
conflict, which you have to resolve by hand (IMHO the only sensible
thing to do). If you change any dependency, you re-run the tool and it
tells you all the new conflicts (by comparing with the old version of
the versions file).
harry
>
> That being said, I would support this being more straight-forwardly
> controllable; it's something I looked for when I moved to Ivy. In
> terms of organization would suggest some new dependencyManagement
> configuration section should be introduced with contains this
> information, as well as the conflict management section as the two are
> related, and you would need to specify the semantics of which
> overrides the other when your conflict management information is in
> conflict with your specific version constraints. :)
>
> Scott
>
RE: specify versions separate from dependencies
Posted by Scott Oster <os...@bmi.osu.edu>.
Maybe I'm not seeing the whole picture, but I think this could be
supported in Ivy today (although maybe not as cleanly as you like).
Could you not just make use of the conflict management system (as
previously suggested), by implementing a resolution scheme that took the
"nearest" version in the dependency graph. That is, If A depends on B
and C and B depends on C, you take A's version of C even if it is older
than Bs (as A's version of C is a shorter path through the dependency
graph than B's is).
The issue you mentioned before with this approach is that there is
potentially no conflict if you just want to specify a hard version of
transitive dependencies, even if there is no conflict. I think the way
around this is you simple introduce a dependency on the module you want
to override (thus introducing a conflict). This is a bit of a leaky
abstraction, as your module doesn't directly need this module (just
through transitivity), but I don't see it as a huge issue as to specify
that you require a specific version of a module which you don't directly
depend on, implies to me that you have already leaked that abstraction
(i.e you already know you need it, and want to control the version).
That being said, I would support this being more straight-forwardly
controllable; it's something I looked for when I moved to Ivy. In terms
of organization would suggest some new dependencyManagement
configuration section should be introduced with contains this
information, as well as the conflict management section as the two are
related, and you would need to specify the semantics of which overrides
the other when your conflict management information is in conflict with
your specific version constraints. :)
Scott
-----Original Message-----
From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
Sent: Wednesday, February 27, 2008 9:17 AM
To: ivy-user@ant.apache.org
Subject: Re: specify versions separate from dependencies
If you update your central properties file each time you publish a new
version, and keep using unexpanded properties for revisions in published
ivy
files, it becomes very similar to using latest.integration versions in
your
published files :-) Except that you can override properties before
loading
the central properties file.
But after trying out how the dependencyManagement feature of maven
actually
works, I think we really need to implement something similar in Ivy. The
dependencyManagement feature let you override the revision of any
dependency, including transitive ones, and this can be useful. This is
really in the spirit of flexibility and control over dependencies that I
usually like with Ivy, and on this I think we have to admit that Maven
beats
Ivy. So I think we should provide a similar feature, as easy to use as
maven's one.
Xavier
On Wed, Feb 27, 2008 at 2:32 PM, John Gill <ll...@gmail.com> wrote:
> Sorry if this isn't on the right track of what you are asking, and I
am
> not
> sure I like what I am about to suggest!
>
> As Xavier stated you can put the revisions of the dependencies in a
> properties file, and I guess there is no reason why you couldn't have
one
> big properties file with all the revisions in it (which you would have
to
> maintain somehow which is the bit I don't really like), and then in
your
> ivy.xml file you can reference the properties that you are actually
using.
>
> Maybe, what you could also do is use a post-publish-artifact trigger
(it
> would be better if there was a post-publish trigger rather than one
for
> each
> artifact) to update the central properties file when the new revision
when
> it is published. It might also be possible to have different
properties
> files for different resolvers for the different releases (unstable,
sid,
> experimental). The trigger informs you of the resolver used which
would
> tell
> you which properties file to update using
>
> Is this a good idea? A part of me finds it this idea appealing, but I
am
> not
> convinced it's a good idea. My main problem is that the builds would
not
> be
> totally reproducible, as the central revisions.properties file would
not
> be
> under version control.
>
> On the other hand, maybe I missed the point entirely.
>
>
> On Wed, Feb 27, 2008 at 7:53 PM, Harald Braumann <ha...@unheit.net>
wrote:
>
> > On Wed, 27 Feb 2008 10:27:04 +0100
> > "Xavier Hanin" <xa...@gmail.com> wrote:
> >
> > > On Tue, Feb 26, 2008 at 6:46 PM, Harald Braumann
<ha...@unheit.net>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > is it possible with ivy to specify the versions of dependencies
> > > > separate from the actual dependency specification? Similar to
the
> > > > <dependencyMangement> section in maven's parent pom?
> > >
> > > There is no direct support for this currently in Ivy, what we
usually
> > > suggest is to use properties to specify the revisions, and define
> > > these properties in a separate file. The result is very similar to
> > > the dependency management feature.
> >
> > Fair enough, but like this I can only control direct dependencies.
> > Maybe I should elaborate a bit more about what I want. Please note
> > that I'm only familiar with Maven and only recently started to look
> > into Ivy because I'm not completely satisfied with the former. So I
> > might get the terminology wrong.
> >
> > Consider a project that is made up of multiple independent modules.
> > Then there exists some uber-build, that has all the modules as
> > dependencies and creates an installation package for the whole
project.
> >
> > Many of the dependencies will be present in multiple modules, either
> > directly or indirectly and very often with different versions. If I
> > want to update some dependency, I don't want to go through all my
> > modules and update there but I want to do it in a central place, for
> > both direct and indirect dependencies.
> >
> > The only solution I see so far is to use a separate repository for
the
> > project. But then I'd have to copy the stuff in there manually from
> > other repositories. Certainly doable, but not as nice as just
> > specifying the versions in a file or some such. Compare this to the
> > Debian repository, where you have one pool with all packages and
files
> > that specify the actual versions that go into a release (stable,
> > unstable, sid, experimental). It's kind of a partitioning of a
central
> > repository.
> >
> > Please note that this problem also exists for single modules. Lets
say
> > I have to dependencies, that both depend on foo. Now I update one
> > dependency, the new version of which depends on a new version of
foo.
> > But I don't want to update foo if it's not necessary. Again I would
> > like to be able to specify the versions in a single place.
> >
> > I would be quite surprised if others didn't have the same problems
> > with randomly changing versions of indirect dependencies.
> >
> > Regards,
> > harry
> >
>
>
>
> --
> Regards,
> John Gill
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by John Gill <ll...@gmail.com>.
Hm, yes you're right. I knew there was a reason why the idea didn't feel
right. I was about to write a prototype implementation. I won't bother now
:-)
On Wed, Feb 27, 2008 at 11:17 PM, Xavier Hanin <xa...@gmail.com>
wrote:
> If you update your central properties file each time you publish a new
> version, and keep using unexpanded properties for revisions in published
> ivy
> files, it becomes very similar to using latest.integration versions in
> your
> published files :-) Except that you can override properties before loading
> the central properties file.
>
> But after trying out how the dependencyManagement feature of maven
> actually
> works, I think we really need to implement something similar in Ivy. The
> dependencyManagement feature let you override the revision of any
> dependency, including transitive ones, and this can be useful. This is
> really in the spirit of flexibility and control over dependencies that I
> usually like with Ivy, and on this I think we have to admit that Maven
> beats
> Ivy. So I think we should provide a similar feature, as easy to use as
> maven's one.
>
> Xavier
>
> On Wed, Feb 27, 2008 at 2:32 PM, John Gill <ll...@gmail.com> wrote:
>
> > Sorry if this isn't on the right track of what you are asking, and I am
> > not
> > sure I like what I am about to suggest!
> >
> > As Xavier stated you can put the revisions of the dependencies in a
> > properties file, and I guess there is no reason why you couldn't have
> one
> > big properties file with all the revisions in it (which you would have
> to
> > maintain somehow which is the bit I don't really like), and then in your
> > ivy.xml file you can reference the properties that you are actually
> using.
> >
> > Maybe, what you could also do is use a post-publish-artifact trigger (it
> > would be better if there was a post-publish trigger rather than one for
> > each
> > artifact) to update the central properties file when the new revision
> when
> > it is published. It might also be possible to have different properties
> > files for different resolvers for the different releases (unstable, sid,
> > experimental). The trigger informs you of the resolver used which would
> > tell
> > you which properties file to update using
> >
> > Is this a good idea? A part of me finds it this idea appealing, but I am
> > not
> > convinced it's a good idea. My main problem is that the builds would not
> > be
> > totally reproducible, as the central revisions.properties file would not
> > be
> > under version control.
> >
> > On the other hand, maybe I missed the point entirely.
> >
> >
> > On Wed, Feb 27, 2008 at 7:53 PM, Harald Braumann <ha...@unheit.net>
> wrote:
> >
> > > On Wed, 27 Feb 2008 10:27:04 +0100
> > > "Xavier Hanin" <xa...@gmail.com> wrote:
> > >
> > > > On Tue, Feb 26, 2008 at 6:46 PM, Harald Braumann <ha...@unheit.net>
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > is it possible with ivy to specify the versions of dependencies
> > > > > separate from the actual dependency specification? Similar to the
> > > > > <dependencyMangement> section in maven's parent pom?
> > > >
> > > > There is no direct support for this currently in Ivy, what we
> usually
> > > > suggest is to use properties to specify the revisions, and define
> > > > these properties in a separate file. The result is very similar to
> > > > the dependency management feature.
> > >
> > > Fair enough, but like this I can only control direct dependencies.
> > > Maybe I should elaborate a bit more about what I want. Please note
> > > that I'm only familiar with Maven and only recently started to look
> > > into Ivy because I'm not completely satisfied with the former. So I
> > > might get the terminology wrong.
> > >
> > > Consider a project that is made up of multiple independent modules.
> > > Then there exists some uber-build, that has all the modules as
> > > dependencies and creates an installation package for the whole
> project.
> > >
> > > Many of the dependencies will be present in multiple modules, either
> > > directly or indirectly and very often with different versions. If I
> > > want to update some dependency, I don't want to go through all my
> > > modules and update there but I want to do it in a central place, for
> > > both direct and indirect dependencies.
> > >
> > > The only solution I see so far is to use a separate repository for the
> > > project. But then I'd have to copy the stuff in there manually from
> > > other repositories. Certainly doable, but not as nice as just
> > > specifying the versions in a file or some such. Compare this to the
> > > Debian repository, where you have one pool with all packages and files
> > > that specify the actual versions that go into a release (stable,
> > > unstable, sid, experimental). It's kind of a partitioning of a central
> > > repository.
> > >
> > > Please note that this problem also exists for single modules. Lets say
> > > I have to dependencies, that both depend on foo. Now I update one
> > > dependency, the new version of which depends on a new version of foo.
> > > But I don't want to update foo if it's not necessary. Again I would
> > > like to be able to specify the versions in a single place.
> > >
> > > I would be quite surprised if others didn't have the same problems
> > > with randomly changing versions of indirect dependencies.
> > >
> > > Regards,
> > > harry
> > >
> >
> >
> >
> > --
> > Regards,
> > John Gill
> >
>
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
>
--
Regards,
John Gill
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
If you update your central properties file each time you publish a new
version, and keep using unexpanded properties for revisions in published ivy
files, it becomes very similar to using latest.integration versions in your
published files :-) Except that you can override properties before loading
the central properties file.
But after trying out how the dependencyManagement feature of maven actually
works, I think we really need to implement something similar in Ivy. The
dependencyManagement feature let you override the revision of any
dependency, including transitive ones, and this can be useful. This is
really in the spirit of flexibility and control over dependencies that I
usually like with Ivy, and on this I think we have to admit that Maven beats
Ivy. So I think we should provide a similar feature, as easy to use as
maven's one.
Xavier
On Wed, Feb 27, 2008 at 2:32 PM, John Gill <ll...@gmail.com> wrote:
> Sorry if this isn't on the right track of what you are asking, and I am
> not
> sure I like what I am about to suggest!
>
> As Xavier stated you can put the revisions of the dependencies in a
> properties file, and I guess there is no reason why you couldn't have one
> big properties file with all the revisions in it (which you would have to
> maintain somehow which is the bit I don't really like), and then in your
> ivy.xml file you can reference the properties that you are actually using.
>
> Maybe, what you could also do is use a post-publish-artifact trigger (it
> would be better if there was a post-publish trigger rather than one for
> each
> artifact) to update the central properties file when the new revision when
> it is published. It might also be possible to have different properties
> files for different resolvers for the different releases (unstable, sid,
> experimental). The trigger informs you of the resolver used which would
> tell
> you which properties file to update using
>
> Is this a good idea? A part of me finds it this idea appealing, but I am
> not
> convinced it's a good idea. My main problem is that the builds would not
> be
> totally reproducible, as the central revisions.properties file would not
> be
> under version control.
>
> On the other hand, maybe I missed the point entirely.
>
>
> On Wed, Feb 27, 2008 at 7:53 PM, Harald Braumann <ha...@unheit.net> wrote:
>
> > On Wed, 27 Feb 2008 10:27:04 +0100
> > "Xavier Hanin" <xa...@gmail.com> wrote:
> >
> > > On Tue, Feb 26, 2008 at 6:46 PM, Harald Braumann <ha...@unheit.net>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > is it possible with ivy to specify the versions of dependencies
> > > > separate from the actual dependency specification? Similar to the
> > > > <dependencyMangement> section in maven's parent pom?
> > >
> > > There is no direct support for this currently in Ivy, what we usually
> > > suggest is to use properties to specify the revisions, and define
> > > these properties in a separate file. The result is very similar to
> > > the dependency management feature.
> >
> > Fair enough, but like this I can only control direct dependencies.
> > Maybe I should elaborate a bit more about what I want. Please note
> > that I'm only familiar with Maven and only recently started to look
> > into Ivy because I'm not completely satisfied with the former. So I
> > might get the terminology wrong.
> >
> > Consider a project that is made up of multiple independent modules.
> > Then there exists some uber-build, that has all the modules as
> > dependencies and creates an installation package for the whole project.
> >
> > Many of the dependencies will be present in multiple modules, either
> > directly or indirectly and very often with different versions. If I
> > want to update some dependency, I don't want to go through all my
> > modules and update there but I want to do it in a central place, for
> > both direct and indirect dependencies.
> >
> > The only solution I see so far is to use a separate repository for the
> > project. But then I'd have to copy the stuff in there manually from
> > other repositories. Certainly doable, but not as nice as just
> > specifying the versions in a file or some such. Compare this to the
> > Debian repository, where you have one pool with all packages and files
> > that specify the actual versions that go into a release (stable,
> > unstable, sid, experimental). It's kind of a partitioning of a central
> > repository.
> >
> > Please note that this problem also exists for single modules. Lets say
> > I have to dependencies, that both depend on foo. Now I update one
> > dependency, the new version of which depends on a new version of foo.
> > But I don't want to update foo if it's not necessary. Again I would
> > like to be able to specify the versions in a single place.
> >
> > I would be quite surprised if others didn't have the same problems
> > with randomly changing versions of indirect dependencies.
> >
> > Regards,
> > harry
> >
>
>
>
> --
> Regards,
> John Gill
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: specify versions separate from dependencies
Posted by John Gill <ll...@gmail.com>.
Sorry if this isn't on the right track of what you are asking, and I am not
sure I like what I am about to suggest!
As Xavier stated you can put the revisions of the dependencies in a
properties file, and I guess there is no reason why you couldn't have one
big properties file with all the revisions in it (which you would have to
maintain somehow which is the bit I don't really like), and then in your
ivy.xml file you can reference the properties that you are actually using.
Maybe, what you could also do is use a post-publish-artifact trigger (it
would be better if there was a post-publish trigger rather than one for each
artifact) to update the central properties file when the new revision when
it is published. It might also be possible to have different properties
files for different resolvers for the different releases (unstable, sid,
experimental). The trigger informs you of the resolver used which would tell
you which properties file to update using
Is this a good idea? A part of me finds it this idea appealing, but I am not
convinced it's a good idea. My main problem is that the builds would not be
totally reproducible, as the central revisions.properties file would not be
under version control.
On the other hand, maybe I missed the point entirely.
On Wed, Feb 27, 2008 at 7:53 PM, Harald Braumann <ha...@unheit.net> wrote:
> On Wed, 27 Feb 2008 10:27:04 +0100
> "Xavier Hanin" <xa...@gmail.com> wrote:
>
> > On Tue, Feb 26, 2008 at 6:46 PM, Harald Braumann <ha...@unheit.net>
> > wrote:
> >
> > > Hi,
> > >
> > > is it possible with ivy to specify the versions of dependencies
> > > separate from the actual dependency specification? Similar to the
> > > <dependencyMangement> section in maven's parent pom?
> >
> > There is no direct support for this currently in Ivy, what we usually
> > suggest is to use properties to specify the revisions, and define
> > these properties in a separate file. The result is very similar to
> > the dependency management feature.
>
> Fair enough, but like this I can only control direct dependencies.
> Maybe I should elaborate a bit more about what I want. Please note
> that I'm only familiar with Maven and only recently started to look
> into Ivy because I'm not completely satisfied with the former. So I
> might get the terminology wrong.
>
> Consider a project that is made up of multiple independent modules.
> Then there exists some uber-build, that has all the modules as
> dependencies and creates an installation package for the whole project.
>
> Many of the dependencies will be present in multiple modules, either
> directly or indirectly and very often with different versions. If I
> want to update some dependency, I don't want to go through all my
> modules and update there but I want to do it in a central place, for
> both direct and indirect dependencies.
>
> The only solution I see so far is to use a separate repository for the
> project. But then I'd have to copy the stuff in there manually from
> other repositories. Certainly doable, but not as nice as just
> specifying the versions in a file or some such. Compare this to the
> Debian repository, where you have one pool with all packages and files
> that specify the actual versions that go into a release (stable,
> unstable, sid, experimental). It's kind of a partitioning of a central
> repository.
>
> Please note that this problem also exists for single modules. Lets say
> I have to dependencies, that both depend on foo. Now I update one
> dependency, the new version of which depends on a new version of foo.
> But I don't want to update foo if it's not necessary. Again I would
> like to be able to specify the versions in a single place.
>
> I would be quite surprised if others didn't have the same problems
> with randomly changing versions of indirect dependencies.
>
> Regards,
> harry
>
--
Regards,
John Gill
Re: specify versions separate from dependencies
Posted by Harald Braumann <ha...@unheit.net>.
On Wed, 27 Feb 2008 10:27:04 +0100
"Xavier Hanin" <xa...@gmail.com> wrote:
> On Tue, Feb 26, 2008 at 6:46 PM, Harald Braumann <ha...@unheit.net>
> wrote:
>
> > Hi,
> >
> > is it possible with ivy to specify the versions of dependencies
> > separate from the actual dependency specification? Similar to the
> > <dependencyMangement> section in maven's parent pom?
>
> There is no direct support for this currently in Ivy, what we usually
> suggest is to use properties to specify the revisions, and define
> these properties in a separate file. The result is very similar to
> the dependency management feature.
Fair enough, but like this I can only control direct dependencies.
Maybe I should elaborate a bit more about what I want. Please note
that I'm only familiar with Maven and only recently started to look
into Ivy because I'm not completely satisfied with the former. So I
might get the terminology wrong.
Consider a project that is made up of multiple independent modules.
Then there exists some uber-build, that has all the modules as
dependencies and creates an installation package for the whole project.
Many of the dependencies will be present in multiple modules, either
directly or indirectly and very often with different versions. If I
want to update some dependency, I don't want to go through all my
modules and update there but I want to do it in a central place, for
both direct and indirect dependencies.
The only solution I see so far is to use a separate repository for the
project. But then I'd have to copy the stuff in there manually from
other repositories. Certainly doable, but not as nice as just
specifying the versions in a file or some such. Compare this to the
Debian repository, where you have one pool with all packages and files
that specify the actual versions that go into a release (stable,
unstable, sid, experimental). It's kind of a partitioning of a central
repository.
Please note that this problem also exists for single modules. Lets say
I have to dependencies, that both depend on foo. Now I update one
dependency, the new version of which depends on a new version of foo.
But I don't want to update foo if it's not necessary. Again I would
like to be able to specify the versions in a single place.
I would be quite surprised if others didn't have the same problems
with randomly changing versions of indirect dependencies.
Regards,
harry
Re: specify versions separate from dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Tue, Feb 26, 2008 at 6:46 PM, Harald Braumann <ha...@unheit.net> wrote:
> Hi,
>
> is it possible with ivy to specify the versions of dependencies
> separate from the actual dependency specification? Similar to the
> <dependencyMangement> section in maven's parent pom?
There is no direct support for this currently in Ivy, what we usually
suggest is to use properties to specify the revisions, and define these
properties in a separate file. The result is very similar to the dependency
management feature.
Xavier
>
>
> Regards,
> harry
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/