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 <[email protected]> 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/i...@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. > >
