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 Mon, 15 Dec 2008 07:55:55 GMT
Mitch,

Thanks for thoughts and feedback, much appreciated.

If I were doing this in an ideal world I would probably go down your
route of persisting this information separately and then use a tool to
generate Ivy files for the repository that augments static information
across releases.

However I want to avoid the need for an additional data source and hence
wondered if I could (and would it be right to) solely use the existing
Ivy infrastructure to achieve my goals.

I'd be interested to hear other people's thoughts on overloading the use
of an Ivy file as a per-module Ivy descriptor rather than just a
per-revision-of-module Ivy descriptor.

I agree that over time an Ivy module's description can change. However
in our environment (both for in-house and 3rd party libraries) the
general gist of what a project is providing will not change. The release
might have some additional information such as key features of that
specific release but the project level description would stay the same.

Regards,

Jeff

On Sun, 2008-12-14 at 14:38 -0800, Mitch Gitman wrote:
> 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
> locations:
> * 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,
> i.e.:
> * 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
> and GROUPS_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
> *ModuleDescriptor
> *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 <jeff@cooljeff.co.uk>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 <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