ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: specify versions separate from dependencies
Date Thu, 28 Feb 2008 08:27:52 GMT
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" <xavier.hanin@gmail.com> wrote:
>
> > On Wed, Feb 27, 2008 at 6:35 PM, Harald Braumann <harry@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/

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