On 9/19/07, Jing Xue <[EMAIL PROTECTED]> 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/
