0

I am looking to separate development and production environments by publishing jars to ivy with live and dev qualifiers.

I am looking for a way to trigger ivy from projects that have these dependencies to automatically grab the latest from these environments based on the ant build file.

I am new to ant and ivy and am not finding documentation on if this is possible or not.

Basically, build-live in ant would trigger resolve-live that would use ref="[1.live.0,)", however we would also need a default one for developers in an Eclipse environment to automatically pick up dependencies through the plugin.

code123456
  • 98
  • 8

1 Answers1

0

You have not indicated what type of repository you are using. I'm going to assume you are not using a Maven repository manager to manage your release repository. Some of these support remote workflow to manage what I like to call "release candidates" (for an example take a look at the staging feature provided by Sonatype Nexus)

For a pure ivy solution I first recommend reading the best practice documentation, specifically the section titled "Dealing with integration versions".

When publishing a new ivy module version one can set the status field. Out of the box ivy supports "integration", "milestone" or "release" but even these can be extended. The status is a label or metadata attribute that appears in the info field of the published ivy file within the ivy repository.

How does this work? When publishing the module as follows:

<ivy:publish resolver="???" pubrevision="1.0.1" status="integration">
   <artifacts pattern="build/artifacts/jars/[artifact].[ext]" />
   <artifacts pattern="build/artifacts/zips/[artifact].[ext]" />
</ivy:publish>

This states that the release 1.0.1 is an integration release.

This then enables the functionality you're looking for. Ivy's dynamic revisions capability can be used to automatically download the latest version with a particular status as follows:

<dependency org="acme" name="foo" rev="latest.integration" />

Update

Once a module is published into the repository it cannot be changed. Doing so could potentially break builds that rely on that version. Think about, if you change the status of a build how to communicate that change? Instead you use the "status" to indicate how stable a version is. Open source projects will frequently publish several "general availability" or "milestone" releases before the finally approved major version.

To do what you want to do requires server-side repository file management. I recommend looking at the "staging" suite in Sonatype Nexus. This feature keeps each pending release in a temp repo until it's finally approved and merged into the main release area.

Community
  • 1
  • 1
Mark O'Connor
  • 76,015
  • 10
  • 139
  • 185
  • I am using an ivy repository. The problem with this and the way I was doing things previously, is that I'm looking for a way to dynamically pick the rev. – code123456 Jun 23 '15 at 23:24
  • I am using an ivy repository. The problem with this and the way I was doing things previously, is that I'm looking for a way to dynamically pick the rev. For example: `rev="default.revision"` which will grab the latest of any published dependency, but when building for production, ant will overwrite`"default.revision"` (or by some other mechanism) to be `"latest.live"`. For some context, the reason I am looking to do this is because there are so many projects that depend on these jars. – code123456 Jun 23 '15 at 23:30
  • @deano I have included a link to ivy's documentation on dynamic revisions. Use "latest.release" or "latest.milestone". If you really want you can extend your project to include a "live" status but I don't think you'll really need that. – Mark O'Connor Jun 24 '15 at 00:59
  • So are you saying there's no way to automatically have ivy change the status or revision based on context? For example I would want to always grab the latest jars no matter what unless I'm building for production, then I would want the latest live jars. I'm not seeing how this is saving me from having to manually go in and update the revision or status. – code123456 Jun 24 '15 at 10:17
  • I'm not sure we are still on the same page. The process that publishes the jars for the different environments is all set. For production it publishes as 1.live.. For development it publishes 1.dev.. In Ivy.xml we have something like `` What I want to do is replace the `rev=""` to something like `rev="[1.default.0,)"` that will grab development in most cases **unless** we do a build for production, in which case it will overwrite default to be live, so I'm assuming default would be a variable that gets overwritten. – code123456 Jun 25 '15 at 21:16
  • @deano Putting strings into the revision numbers will work, but you'll encounter problems when ivy attempts to determine which release is the latest (Strings in revision numbers can prevent a correct numeric comparison). My suggestion is to use the existing dynamic revision feature that is built into ivy. It amounts to the same thing. The "status" indicates the release type. If you really really want to use "live" and "dev" as status fields you can customize your build. Personally I find the default statuses work fine for me. – Mark O'Connor Jun 25 '15 at 21:50
  • Right... If I do it either way is there any way that automates picking the correct dependency? I will always have to go into ivy and choose latest or integration. Is that correct or am I missing something? I only want it to pick latest.integration when I build for production, otherwise (in developing the app) I want to grab the latest no matter what. – code123456 Jun 25 '15 at 23:20
  • I think what you're missing is that the ivy deliver task can resolve the dependencies at publish time See http://stackoverflow.com/questions/8384024/automate-ivy-revision-increase-for-all-my-projects-using-ant-script/8392205#8392205. This way the ivy file in your repository has a dependency against a fixed revision. When creating a release you'll normally be building against the last integration version jars from your own project and the latest release or milestone of 3rd party teams. – Mark O'Connor Jun 26 '15 at 00:07
  • Thanks for the help, Mark. – code123456 Jun 26 '15 at 00:08