Don't consider this an authoritative answer, and I know this isn't the answer you want to hear. But I tend to believe that the "best practice" approach to distinguishing between different statuses of the same module is to literally use different repositories.
So you would have an integration repository to which the ivy:publish would specify status="integration". And you would have a pilot repository to which the ivy:publish would specify status="milestone" or status="release". And finally your production repository would be all status="release". Then you would switch between different Ivy settings depending on which repository you're building against. At this point you're ensured that no integration versions will leak into your release builds. As for the potential for conflicts in your local cache, this is where I don't feel comfortable giving an authoritative answer. But if you know that throughout your dependency chain you're depending on "latest.integration" or "latest.integration", then you should be good. However, if in your dependency element in an ivy.xml you're specifying a particular revision as opposed to "latest.integration" or "latest.release", I don't know if there's a way to make it only a particular status. Now, there's another approach that would address the problem of getting confused between integration and release versions of the same Ivy module, although I don't think addressing this problem should be the primary rationale for taking this approach. In a development environment where you're doing active development in the trunk and using branches to prepare milestones and releases, it makes sense to give those milestones and releases slightly different versions/revisions. Never mind Ivy. So suppose active development is going on on mywebapp 2.0. Then you want to prepare a release, alpha1. So you branch mywebapp 2.0 to create mwebapp 2.0_alpha1. If you follow a convention like this, from here on in you know that revision="2.0" will always give you an integration version and revision="2.0_alpha1" will always give you a milestone or release version. A more Ivy-centric variation on this technique of having the revision itself distinguish between integration and release builds is to literally incorporate some marker of the integration build into the revision. If you're doing what one would call snapshot versioning where each latest integration build by the CI server replaces the previous one for that given revision and you care to express the fact it's a "snapshot" that in the revision (like Maven does I understand), then you would be publishing mywebapp rev="2.0-SNAPSHOT" (or whatever naming convention you follow). When it comes time to do a release, it makes sense that that -SNAPSHOT suffix will no longer be there. Likewise, if you're doing what I would call prolific versioning where each latest integration build creates its own unique revision--so the CI server is adding more and more revisions to the integration repository--then you're ensured that each integration build has its own unique revision like "2.0.20090510105801" with a timestamp. Or maybe "2.0.212" where you're keeping track of an incrementing build number. I'm inclined to think that, with this approach, when you're ready to do a release, you would just call it "2.0" or "2.0_alpha1" or "2.0.0" or "2.0_ga"--whatever. Whatever you call it the fine-grained timestamp or build number is no longer there. Forgive me for making a magnum opus out of this, but this is a fairly complicated topic. On Tue, May 19, 2009 at 10:26 AM, Vonnahme, Paul < [email protected]> wrote: > I'm hoping someone else is in a similar situation. We have some utility > jars used by multiple projects. These jars have three different versions: > one each for our test, pilot, and production environments. Therefore I > believe each of the versions needs to be published so it will be available > for multiple apps to use. > > When an app builds, it should get the latest version of the jar depending > on the environment. The ivy.xml would contain: > <dependency org="principal" name="utility_jar" > rev="latest.integration"/> . > > I'd like to do something like: > ant compile -Denv=test > for it to build with the latest test jar, -Denv=pilot to build with the > latest pilot jar, etc. > > My idea is to have three different versions of the settings file, and just > change the root of a resolver based on the environment. > <property name="ivy.shared.default.root" > value="/IvyRepository/test"/> would specify the root of the 'shared' > resolver for the test environment. "/IvyRepository/pilot" would exist for > pilot, etc. > > The problem I see with this is that the local cache would contain versions > from all environments (depending on which one you built with last) and would > have to be cleared out every time. > > Am I overthinking the problem? Is there a way to only have one repository > but still be able to specify the latest jar from a specific environment? > > Thanks, > Paul > > > > > > > > -----Message Disclaimer----- > > This e-mail message is intended only for the use of the individual or > entity to which it is addressed, and may contain information that is > privileged, confidential and exempt from disclosure under applicable law. > If you are not the intended recipient, any dissemination, distribution or > copying of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by > reply email to [email protected] and delete or destroy all copies of > the original message and attachments thereto. Email sent to or from the > Principal Financial Group or any of its member companies may be retained > as required by law or regulation. > > Nothing in this message is intended to constitute an Electronic signature > for purposes of the Uniform Electronic Transactions Act (UETA) or the > Electronic Signatures in Global and National Commerce Act ("E-Sign") > unless a specific statement to the contrary is included in this message. > > While this communication may be used to promote or market a transaction > or an idea that is discussed in the publication, it is intended to provide > general information about the subject matter covered and is provided with > the understanding that The Principal is not rendering legal, accounting, > or tax advice. It is not a marketed opinion and may not be used to avoid > penalties under the Internal Revenue Code. You should consult with > appropriate counsel or other advisors on all matters pertaining to legal, > tax, or accounting obligations and requirements. >
