ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Sinclair <j...@cooljeff.co.uk>
Subject Re: Using ivy.xml files to describe common module information
Date Sun, 14 Dec 2008 19:15:13 GMT
Mitch,

Thanks for the response.

I understand the difference between source ivy.xml files and delivered
ivy.xml files. What I'm looking at here is to provide some additional
meta-data in the repository to describe projects (i.e. commons-logging,
xerces, etc) rather than specific releases of those projects (3.2.0,
2.9.1, etc).

Perhaps I was not clear as to why I want to do this.

I have a hierarchical UI that allows you to drill down by organisation,
project and then release. The release pages are simple, they source
information about a specific release from the ivy.xml files contained in
the repository. The project pages list available releases (by querying
the repository and listing releases for a module) but they also display
information about the project that is common amongst all releases. Users
can then click on a specific release listed on the project page to find
more information about that release.

So my initial requirement is not really about what gets delivered, it's
more about how I should go about persisting this common information. I
want to keep all of the information in the repository itself. I have a
choice: I can either store an ivy.xml file at the module level in the
repository to describe the common information using the Ivy schema or I
can come up with my own custom schema to do this.

I'm very much a purist and therefore wanted to make sure that I was not
abusing the ivy schema to store this additional meta data since to me an
ivy.xml file represents a release (whether the actual revision is fixed
in source or dynamically generated when being delivered) rather than a
project. I saw that Ivy might be introducing a parent mechanism which
made me think that it might be ok to use the Ivy schema to capture
common meta-data amongst releases for a given project.

I was wondering if:

- it makes sense to store common project information in an ivy.xml.
- Ivy will happily generate a ModuleDescriptor from such an ivy.xml file
(since I don't want to have to write custom parsing code if Ivy can
already do this for me).
- such an ivy.xml file could be used with the parent mechanism outlined
in IVY-742.

Regards,

Jeff

On Sun, 2008-12-14 at 08:21 -0800, Mitch Gitman wrote:
> 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
View raw message