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: Using ivy.xml files to describe common module information
Date Sun, 14 Dec 2008 16:21:37 GMT
One small correction to what I just wrote. Noted inline below.

On Sun, Dec 14, 2008 at 8:04 AM, Mitch Gitman <mgitman@gmail.com> wrote:

> Jeff:
> At the risk of not directly answering your question, let me take a step
> back and make sure you really need to do what you want to.
>
> Let's say you have a Java project *coolweblayer *that will produce a
> module with organisation="coolteam" and module="coolweblayer". Let's say
> the info element of your ivy.xml file *in the project source* specifies
> organisation, module, revision (though it technically doesn't have to), full
> description.
>
> When you invoke the *ivy:publish *Ant task or the *ivy:deliver *Ant task,
> the Ivy XML file that gets generated does preserve all the extra metadata
> under /ivy-module/info, like /description. (I'm not sure about custom
> elements.) So in that respect, I'm not sure what the roadblock is you're
> running into. If you compare your ivy.xml in source to each ivy.xml that has
> been published in your repository for the *coolweblayer *module, you
> should find that all that extra content under /ivy-module/info, except for
> the revision attribute and publication date, is the same, unless you've
> changed it in source as you've gone along.


The revision attribute's value may not even be changed, if you're using more
of a snapshot approach to "Dealing with integration versions" on the Best
Practices page <http://ant.apache.org/ivy/history/trunk/bestpractices.html>,
as opposed to versioning aggressively, *and *if you haven't manually upped
the revision.

>
>
> By the way, the /ivy-module/info@revision attribute is optional in your
> source ivy.xml file. There is one style of Ivy development where you want to
> be using the revision specified in the source Ivy file to keep track of the
> revision to publish. There is another style of Ivy development where you
> leave the revision attribute out of the source Ivy file and rely on the
> current state of your Ivy repository to determine what revision to publish.
> You can do the latter via the *ivy:buildnumber *Ant task. In this latter
> style, when you want to increment your revision, you'll have to specify it
> manually in some way that gets passed to *deliver *or *publish*.
>
> This latter style of development is discussed in some detail in a recent
> thread on this list:
>
> http://www.nabble.com/buildnumber-Ant-task---automated-updates-of-ivy.xml-td20583215.html
>
> Anyway, from a high level, there's quite a bit of content that can be
> specified in an Ivy file, with subtle differences between Ivy files in
> source and the corresponding Ivy files published in the repository for the
> given module. But if you're only producing new revisions as you go along,
> you should find that most of that content remains consistent.
>

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