Different dependencies for integration, milestone, release

[Alex Kiesel <al...@kiesel.name>]

Hi,

I'd like to deploy a build system on top of Ivy. Currently, I face one
problem: I'd like to have different dependencies when integration,
milestone or release is built. A release should only depend on other
releases, milestones should require releases and/or milestones and
integration build may take anything.

I'd like to leave the rev="" setting in the dependency untouched. Is
there one parameter to <ivy:resolve> that would help me?

Regards,
-Alex

Re: Different dependencies for integration, milestone, release

[Alex Kiesel <al...@kiesel.name>]

Hi Mitch,

On 24 March 2011 14:58, Mitch Gitman <mg...@gmail.com> wrote:
> The best and most common approach I'm aware of for handling this is to have
> your Ivy settings including three different Ivy settings files, one for each
> stage/status. Which settings to include is determined by a property. The
> default value, and the one developers and the dev CI server would use, would
> pick up the integration Ivy settings. This property would be overridden,
> preferably by a value in a properties file under .ivy2 or elsewhere in
> user.home, for milestone and release builds.
>
> Note that your integration Ivy settings wouldn't just have integration Ivy
> resolvers. It would have a chain of integration, milestone, and release. The
> milestone Ivy settings would have a chain of milestone and release. The
> release Ivy settings would have just release resolvers. This is presuming
> that you've published your modules to different directories/locations--to
> different Ivy repositories, literally--depending on their status
> (preferable), or you at least have some way to distinguish between them
> based on pattern within the same repo (acceptable).

I have solved this - based on your recommendation - like this:

I have declared three different resolvers: integration, milestone,
release. Each of these exist "on it's own". I have further created
three "lookup" resolvers, which contain references to the first three:

lookup.integration -> [integration, milestone, release]
lookup.milestone -> [milestone, release]
lookup.release -> [release]

First, I run <ivy:info file="ivy.xml"/> to retrieve the current status
from ivy.xml; this automatically set's up ivy, already. Then, an ant
property's being set: "build.mode", with the value of "ivy.status"
property.

In a subsequent step, I call <ivy:settings/> again. In the referenced
settings file, besides the mentioned three resolvers and their
corresponding "lookup" resolvers, there's the line

<settings defaultResolver="${build.mode}"/>

This does what I wanted. Thanks for the hints! :-) Btw, why I need to
do it this (seems a bit complicated) was because I found no way to
specify a resolver when doing a resolve - the only time it is possible
to specify a direct resolver is when doing <ivy:publish/>.

Regards,
-Alex

Re: Different dependencies for integration, milestone, release

[Mitch Gitman <mg...@gmail.com>]

The best and most common approach I'm aware of for handling this is to have
your Ivy settings including three different Ivy settings files, one for each
stage/status. Which settings to include is determined by a property. The
default value, and the one developers and the dev CI server would use, would
pick up the integration Ivy settings. This property would be overridden,
preferably by a value in a properties file under .ivy2 or elsewhere in
user.home, for milestone and release builds.

Note that your integration Ivy settings wouldn't just have integration Ivy
resolvers. It would have a chain of integration, milestone, and release. The
milestone Ivy settings would have a chain of milestone and release. The
release Ivy settings would have just release resolvers. This is presuming
that you've published your modules to different directories/locations--to
different Ivy repositories, literally--depending on their status
(preferable), or you at least have some way to distinguish between them
based on pattern within the same repo (acceptable).

On Thu, Mar 24, 2011 at 4:55 AM, Alex Kiesel <al...@kiesel.name> wrote:

> Hi,
>
> I'd like to deploy a build system on top of Ivy. Currently, I face one
> problem: I'd like to have different dependencies when integration,
> milestone or release is built. A release should only depend on other
> releases, milestones should require releases and/or milestones and
> integration build may take anything.
>
> I'd like to leave the rev="" setting in the dependency untouched. Is
> there one parameter to <ivy:resolve> that would help me?
>
> Regards,
> -Alex
>

RE: Different dependencies for integration, milestone, release

[Keith Hatton <ke...@publishingtechnology.com>]

The value in the rev="..." attribute can be a property, so you can have, for example, rev="latest.${foo}" in your ivy.xml, and work out what the value of ${foo} should be in your Ant script (just make sure you do this prior to calling any <ivy:...> tasks).

HTH
Keith


-----Original Message-----
From: Alex Kiesel [mailto:alex@kiesel.name] 
Sent: 24 March 2011 11:56
To: ivy-user
Subject: Different dependencies for integration, milestone, release

Hi,

I'd like to deploy a build system on top of Ivy. Currently, I face one
problem: I'd like to have different dependencies when integration,
milestone or release is built. A release should only depend on other
releases, milestones should require releases and/or milestones and
integration build may take anything.

I'd like to leave the rev="" setting in the dependency untouched. Is
there one parameter to <ivy:resolve> that would help me?

Regards,
-Alex

Re: Different dependencies for integration, milestone, release

[Mitch Gitman <mg...@gmail.com>]

Following up Keith's response...

Certainly, it's a good practice to use a revision suffix to distinguish
integration builds from milestone/release builds. For example:
1.0-SNAPSHOT as opposed to 1.0-alpha1 or 1.0 (release)

And technically, you can make a property placeholder part of a
dependency@rev value in an ivy.xml.

However, in practice, picking up all or part of the dependency's rev
attribute from a property introduces a layer of indirection that probably
doesn't gain you anything at the cost of inconvenience, potential errors
introduced by having more moving parts, and worst of all, potentially losing
reproducibility on your release builds.

If you're a developer working against trunk or an integration branch (to use
the Subversion terms), you're going to want to see right in your ivy.xml
whether you're depending on 1.0-SNAPSHOT (or latest.integration) or 1.0 (or
latest.release) of something rather than having to look up a property
elsewhere to figure out what you're depending on. And when you're getting
ready to make a release (whether milestone or release) out of a build on an
integration branch, you'd want to have the control that comes with manually
removing the -SNAPSHOT suffix from your dependencies one by one to make sure
the dependency still works.

Even if you have an automated mechanism to make sure that, in preparation
for a release, all the dependency revisions identifying milestone/release
dependencies have the suffix stripped, that's still going to be a one-off
change that never has to be controlled subsequently. The milestone and
release ivy.xml files, within immutable projects as represented by tags in
source control, will and should have hardcoded revisions in their
dependencies. They'll never change once they're tagged.

As for the potentially cool feature of switching back and forth between
latest.integration and latest.milestone and latest.release based on one
property, keep in mind that even though your current project is integration,
that doesn't necessarily mean that its dependencies are all integration. And
where you do have some release-worthy dependencies, you're in a position to
know and just specify the hardcoded version. Putting latest.milestone and
latest.release in the dependencies when you're ready to tag a release
(whether milestone or release) really doesn't buy anyone anything. No one is
doing active development against a tag and at this point you know precisely
what the revisions you're depending on are.

Worst, it's a serious mistake to say "Give me the latest release for a
dependency" rather than "Give me this particular release for a dependency"
on a release build because that puts your release at the mercy of whatever
the latest is in the Ivy repository. This means that you've created a
release for foo 1.0 that depends on bar 2.0. Subsequently bar 2.1 comes out.
Then when you go to release foo 1.0, you get bar 2.1 for latest.release,
which is not what you wanted. You've just lost the reproducibility on your
release builds.

On Thu, Mar 24, 2011 at 7:08 AM, Keith Hatton <
keith.hatton@publishingtechnology.com> wrote:

> The value in the rev="..." attribute can be a property, so you can have,
> for example, rev="latest.${foo}" in your ivy.xml, and work out what the
> value of ${foo} should be in your Ant script (just make sure you do this
> prior to calling any <ivy:...> tasks).
>
> HTH
> Keith
>
>
> -----Original Message-----
> From: Alex Kiesel [mailto:alex@kiesel.name]
> Sent: 24 March 2011 11:56
> To: ivy-user
> Subject: Different dependencies for integration, milestone, release
>
> Hi,
>
> I'd like to deploy a build system on top of Ivy. Currently, I face one
> problem: I'd like to have different dependencies when integration,
> milestone or release is built. A release should only depend on other
> releases, milestones should require releases and/or milestones and
> integration build may take anything.
>
> I'd like to leave the rev="" setting in the dependency untouched. Is
> there one parameter to <ivy:resolve> that would help me?
>
> Regards,
> -Alex
>
>