Alan, I agree that configurations are a powerful--indeed a
necessary--feature of Ivy. But I would also maintain that Ivy confs are
about features, not about the problem Paul is trying to address, which is
distinguishing between integration and release builds. For that problem I
believe the techniques at hand come down to some combination of:
- Depending on status="latest.integration", etc. And Kirby above offers a
good technique for changing "latest.${...}" on the fly.
- Maintaining separate integration and release Ivy repositories.
- Establishing versioning conventions (probably in concert with the
version control system) that lead to integration publications having
distinctly different revisions than release publications. That is, you can
tell just by looking at the form of rev="..." whether it's integration or
release.
Consider it this way. Even if you have an Ivy conf to give you your
in-memory database, you're still going to need the other Ivy conf to give
you your real database--*even for your continuous integration builds*. Now
you could say, "What about the database connection strings? Wouldn't they
qualify for different Ivy confs, so you would need one Ivy conf for dev and
another for QA and yet another for production?" I would maintain that even
here you're blurring the line, but then application configuration is a whole
'nuther topic in its own right.
On Tue, May 19, 2009 at 2:11 PM, Alan Hohn <li...@anvard.org> wrote:
>
> On Tue, 19 May 2009, Kirby Files wrote:
>
> Is there any reason not to use varying statuses for the different
>> environments?
>>
>> http://ant.apache.org/ivy/history/trunk/settings/statuses.html
>>
>>
> This is a good solution if you can have separate downstream projects that
> fetch the JARs for each environment. If your situation is more complicated
> and you need to fetch different versions of an upstream JAR into the same
> downstream project for different purposes (unit test, deployment, etc.),
> look into Ivy configurations. They're designed to do exactly what you want.
>
> In our project we have a unit testing version of some of our projects (uses
> in-memory database support, etc.) and Ivy configurations let us grab one
> version of the JAR to run tests in the downstream and then grab a different
> version when it's time to package an EAR file.
>
> http://ant.apache.org/ivy/history/2.1.0-rc1/tutorial/conf.html
>
> Best regards,
> Alan
>
>
