ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mitch Gitman" <>
Subject Re: Using ivy.xml files to describe common module information
Date Sun, 14 Dec 2008 16:04:14 GMT
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/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:

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 <>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:
> 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

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