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 Thu, 21 May 2009 18:05:03 GMT
Few responses inline.

On Thu, May 21, 2009 at 10:37 AM, Vonnahme, Paul <
Vonnahme.Paul@principal.com> wrote:

> [OT] I wasn't aware you could use ant variables in the ivy.xml files.  Very
> good to know, and I'm sure it will come in handy as I continue to experiment
> with ivy.
>

Small correction. You can use Ant properties (not variables) in
ivysettings.xml files, *not *ivy.xml files as you say.


> >
> > and run in test environment:
> >    ant -Divy.build.env=integration compile
> >
> > You can even default the property in ivysettings.xml, with an
> > override=false setting, to ensure your command-line param
> > takes precedence.
> >
> > Now just publish your utility modules with the appropriate
> > statuses, and everything should Just Work, right?
>
> I tried this out, and at first it seemed like the answer I had been looking
> for.  However, then I noticed a few resolves that weren't happening how I
> expected.  I found this in the documentation (
> http://ant.apache.org/ivy/history/latest-milestone/ivyfile/dependency.html
> ):
> "latest.[any status]
> selects the latest revision of the dependency module with **at least the
> specified status**."  (Emphasis mine)
>
> For our environment if I run:
>        ant -Divy.build.env=pilot compile
> I would need it to compile only with dependencies that have a pilot status.
>  Since ivy statuses are hierarchical, I would run the risk of pulling a
> dependency from a higher status.


If I were you and I really insisted on (A) having one Ivy repository for all
my different statuses/stages and (B) not distinguishing between integration
and milestone/release via the revision value itself, then I would ask
myself, "Isn't this default rule really what I want after all?"

Suppose I have a web service project that is depending on a domain project
and I know I haven't had to make any changes to the domain project since its
last release to support the new pilot of your web service, then that "at
least the specified status" rule makes perfect sense. You don't want to have
to produce a new pilot version of your domain project to support a new pilot
version of your web service project.

Beyond that, if you found out after all that you were happy with that rule,
you might as well just make pilot correspond to the built-in "milestone"
status, although integration/milestone/release vs. integration/pilot/release
is a trivial matter.


>
> One way I could guarantee the status would be to put
>    <status name="${ivy.build.env}" integration="false"/>
> as my highest level status.


It sounds like to accomplish this, you would have to dynamically import an
Ivy settings fragment into your main Ivy settings, like
ivysettings-statuses-${ivy.build.env}.xml. Then if the build env is
integration, the imported file defines only one status, integration. If the
build env is pilot, the imported file defines two status, integration and
pilot. Etc.

So it sounds like this could be done, although I would still question the
motivation.


>
> I will continue to experiment more with this option as well the option of
> multiple repositories.
>
> Thanks to all for your responses.
>
> 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