Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@ant.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Subject: Re: Using ivy.xml files to describe common module information
From: Jeffrey Sinclair <jeff@cooljeff.co.uk>
To: ivy-user@ant.apache.org
In-Reply-To: <21012174.post@talk.nabble.com>
References: <1229255969.5655.23.camel@Lini>  <21012174.post@talk.nabble.com>
Content-Type: text/plain
Date: Sun, 21 Dec 2008 09:35:07 +0000
Message-Id: <1229852107.5984.13.camel@Lini>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

> 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