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 22:38:25 GMT
OK, I think I have a bit better picture of your motivation now. Not that you
weren't being clear before.

Let me try to restate with an example. Your Ivy repository specifies a
third-party module, commons-logging. Your repository has the following
* org.apache
    * commons-logging
        * 1.0.4
        * 1.1

If you look at the ivy.xml files in 1.0.4 and 1.1, you'll find that there's
a lot of redundancy between the two, especially in the extra per-module
description you put in. Your concern is about that redundancy. And this
concern is the same for in-house modules as well as for third-party modules.

Or let me restate this concern in more fundamental terms. If I were acting
as Jeff's advocate, I would say: "What is the best way to capture metadata
that is common across multiple revisions of the same module? When you think
about it, an ivy.xml file describes a revision of a module, but it almost
seems like there should be some sort of Ivy file that describes a module
across all of its revisions. So, shouldn't there be per-module Ivy
descriptors, rather than just per-revision-of-module Ivy descriptors?"

These are some interesting questions and concerns, and I'd love to hear
someone else address them. But I can tell you, from my perspective, why I
don't share these concerns.

As things stand now, an Ivy descriptor does effectively operate more at a
per-module level than at a per-revision-of-module level. It just so happens
that your module does have a revision, the current revision, associated with
it, whether explicitly (in the file itself) or implicitly. When it comes to
Ivy descriptors, Ivy doesn't "want" you to think in a hierarchical fashion,
* modules
    * revisions

Ivy "wants" you to think in terms of modules that have different states as
you go along in time.***

It's sort of analogous to a database schema where you don't want to make the
history of changes to the schema part of the schema itself. For example, you
have USERS and GROUPS tables, and you might also have USERS_HISTORY
tables to keep track of the changes that have been made to the corresponding
tables over time. But you don't want to make the _HISTORY stuff part
of the USERS
or GROUPS tables themselves.

If I were you, I would be less concerned about this when it comes to
in-house modules, where I am starting with Java source and an ivy.xml in
source and dumping artifacts and ivy.xml files in the repository as I go
along. *To me, it is perfectly legitimate to expect that this seemingly
static module-level metadata will change over time, so that it will not be
common across all revisions. In any event, there's always a single
per-module source file for these various generated Ivy files--namely, the
ivy.xml in your project source.*

Now, with third-party projects, I can see how this module-level metadata
could be static across revisions, although even that is presuming that your
third-party dependencies never evolve enough between revisions that their
basic description needs to change.

If I were you, and I was sure that my third-party dependencies' module-level
data was static and I was concerned about all this redundancy, I would go
ahead and *generate *those ivy.xml files that wind up in the Ivy repository.
And to do so, I would write my own Java project that generates the
*from data that I read in from my own persistence store. But this is based
on my own knowledge, and perhaps someone else out there knows an easier way
to accomplish this within the bounds of current Ivy functionality.

** *Please take my feedback with the grain of salt that should be given to
commentary from any member of an open-source project's community. And
considering that Ivy is the kind of tool that allows for numerous styles of
usage, it's a bit presumptuous to say that there's a certain way Ivy "wants"
you to do things.

On Sun, Dec 14, 2008 at 11:15 AM, Jeffrey Sinclair <>wrote:

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

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