You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Jeffrey Sinclair <je...@cooljeff.co.uk> on 2008/12/14 12:59:29 UTC
Using ivy.xml files to describe common module information
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
Re: Using ivy.xml files to describe common module information
Posted by Jeffrey Sinclair <je...@cooljeff.co.uk>.
> Have you already looked at the feature to provide extra-arguments in
the<info> section of the ivy.xml file...
Thanks Marc, I am using the 'extra' namespace to keep hold of some
additional meta data.
I've gone down the route of having a common project.xml file in the
repository to capture the common meta-data across all releases in that
project, hence the structure of my repository is:
[organization]
[module]
project.xml
[ivys]
ivy-[revision].xml
For now, if I need to merge some of the common information in
project.xml into an individual ivy-[revision].xml, I will write a script
to do it and will re-visit this when the parenting mechanism is
implemented in Ivy.
Regards,
Jeff
On Mon, 2008-12-15 at 03:20 -0800, marcdb wrote:
>
> Jeffrey Sinclair wrote:
> >
> > 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?
> >
>
> Jeff,
> Have you already looked at the feature to provide extra-arguments in the
> <info> section of the ivy.xml file:
> http://ant.apache.org/ivy/history/latest-milestone/concept.html#extra
>
> Or something else: make a dependency towards a generic module, which
> describes your project (org=your_project, module=your_project). The module
> descriptor for that project specifies an artifact to be published (e.g. of
> type txt or html) where you can specify all the information that you want
> to.
> <publications>
> <artifact type="txt" />
> </publications>
> Then create in the appropriate location a file "your_project.txt" or
> "your_project.html" that will be published at resolve time in your
> repository. All your modules for your project should then include the
> your_project module as dependency. If you want to update your project-info,
> you simply update that your_project.txt file.
>
> I hope this helps,
>
> Marc
Re: Using ivy.xml files to describe common module information
Posted by marcdb <md...@gmail.com>.
Jeffrey Sinclair wrote:
>
> 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?
>
Jeff,
Have you already looked at the feature to provide extra-arguments in the
<info> section of the ivy.xml file:
http://ant.apache.org/ivy/history/latest-milestone/concept.html#extra
Or something else: make a dependency towards a generic module, which
describes your project (org=your_project, module=your_project). The module
descriptor for that project specifies an artifact to be published (e.g. of
type txt or html) where you can specify all the information that you want
to.
<publications>
<artifact type="txt" />
</publications>
Then create in the appropriate location a file "your_project.txt" or
"your_project.html" that will be published at resolve time in your
repository. All your modules for your project should then include the
your_project module as dependency. If you want to update your project-info,
you simply update that your_project.txt file.
I hope this helps,
Marc
--
View this message in context: http://www.nabble.com/Using-ivy.xml-files-to-describe-common-module-information-tp20999668p21012174.html
Sent from the ivy-user mailing list archive at Nabble.com.
Re: Using ivy.xml files to describe common module information
Posted by Jeffrey Sinclair <je...@cooljeff.co.uk>.
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 <je...@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 <mg...@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.
> > > >
> >
> >
Re: Using ivy.xml files to describe common module information
Posted by Mitch Gitman <mg...@gmail.com>.
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 <je...@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 <mg...@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.
> > >
>
>
Re: Using ivy.xml files to describe common module information
Posted by Jeffrey Sinclair <je...@cooljeff.co.uk>.
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 <mg...@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.
> >
Re: Using ivy.xml files to describe common module information
Posted by Mitch Gitman <mg...@gmail.com>.
One small correction to what I just wrote. Noted inline below.
On Sun, Dec 14, 2008 at 8:04 AM, Mitch Gitman <mg...@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.
>
Re: Using ivy.xml files to describe common module information
Posted by Mitch Gitman <mg...@gmail.com>.
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/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.
On Sun, Dec 14, 2008 at 3:59 AM, Jeffrey Sinclair <je...@cooljeff.co.uk>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
>
>