ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Castrianni <Shawn.Castria...@halliburton.com>
Subject RE: specify versions separate from dependencies
Date Wed, 27 Feb 2008 18:57:04 GMT
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" <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.

Mime
View raw message