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: Resolving Dependencies not to patch level
Date Wed, 19 Sep 2007 06:18:00 GMT
On 9/19/07, Jing Xue <jingxue@digizenstudio.com> wrote:
>
> On Tue, Sep 18, 2007 at 04:46:03PM -0400, Dmitriy Korobskiy wrote:
> >
> > Hence, if you build system is written correctly, you'd use SCM
> > labeling/branching on your repositories (assuming you have repositories
> > under SCM, and not using public repositories) or "delivered" Ivy files
> > to reproduce the builds.
>
> I thought this ought to be trivial, but couldn't find it anywhere - how
> do you specify, at build-time, a different ivy file for publishing the
> same artifact, i.e. a file name different from ivy.xml?


You can specify the name you want for Ivy file at resolve time, no problem.
But I like the process described by Matthias, where a delivered Ivy file is
put in SCM each time you deliver a module. The only drawback I see is
version history of the ivy file, which switched between development versions
and delivered versions. In the original jayasoft build system, we used to
have two ivy files: ivy-dev.xml and ivy-snapshot.xml. Switching between the
two was done by setting a property (and we had two ant targets for that,
'dev-mode' and 'snapshot-mode'. Then the two had different histories, but
you had to remember when checking out a project to call the target
corresponding to the mode you'd like. This could have been improved by
checking in the property set to snapshot mode at each snapshot, and assuming
the dev mode by default.

The reason I'm asking is that if that's possible, we can choose
> different versions of the ivy file when making a build, i.e., use the
> original ivy.xml with dynamic ranges when making development builds, and
> the delivered one with fixed versions when reproducing builds.


That's exactly what is usually recommended to ensure build reproducibility.

I'm not sure about putting repositories directly under version control
> though. IMHO, one of the points to use Ivy or any dependency manage
> tools is so we won't have to check lib/*.jar into SCM.


Yes, but if you don't put your SCM repository in SCM it's difficult to
ensure build reproducibility. You need to be absolutely sure you won't ever
modify any module in your repository. Ever. And I've seen too many times
people modifying a third party module metadata because there were a
dependency missing. IMO dependency management tools like Ivy are useful to
determine the set of dependencies a module need, by using transitive
dependencies resolution and conflict management. But they do not preclude
the use of a SCM for module repository management.

Xavier

Cheers.
> --
> Jing Xue
>



-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://incubator.apache.org/ivy/
http://www.xoocode.org/

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