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. 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. On Sun, Dec 14, 2008 at 3:59 AM, Jeffrey Sinclair <[email protected]>wrote: > ivy-users, > > We have a custom repository at our company and I was looking to provide > some meta-data at the 'module' level that would describe common > information across all revisions for that module: > > * /info/@organisation. > * /info/@module. > * /info/description. > * /info/description/@homepage. > * some custom tags. > > Initially I went down the route of a custom project-descriptor.xml file > rather than re-using the ivy.xml file at the module level. At the time I > was concerned that I would be overloading the use of the ivy.xml file by > using it without a revision and was not sure if Ivy would always support > parsing such an ivy.xml as a valid file. > > Does Ivy consider an Ivy file with just the above information as 'valid' > and would you always be able to parse such an Ivy file into a > ModuleDescriptor? > > I noticed that there is a JIRA for inheritance between Ivy files: > > https://issues.apache.org/jira/browse/IVY-742 > > which has made me re-think using a standard ivy.xml file in favour of > our custom project-descriptor.xml file to describe information common to > all revisions of a module. > > If I were to provide an ivy.xml file with just the above information, > would this be compatible with any new feature that comes from IVY-742 or > is there some other information I will need to add or take into > consideration? > > Regards, > > Jeff > >
