ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@gmail.com>
Subject Re: Published jars for test, pilot, and production environments?
Date Tue, 19 May 2009 18:01:55 GMT
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 <
Vonnahme.Paul@principal.com> 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 Connect@principal.com 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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message