Ivy + Gump

[Ja...@rzf.fin-nrw.de]

I think about the following:
- use Ivy for handling the dependencies of the projects
  --> these specifies the versions they trust
- use Gump for integration builds
  --> check if there are incompatibilities

Is there a way to share the dependency information?


Jan

Re: Ivy + Gump

[Xavier Hanin <xa...@gmail.com>]

On 3/23/07, Steve Loughran <st...@apache.org> wrote:
>
> Gilles Scokart wrote:
> > The sky is the limit...
> >
> > Who never had issues to find/download/install the correct list of
> > dependencies of an antlib?  Or even find the set of antlibs required by
> a
> > build script?
> >
>
> possible changes:
> 1. There was some discussion on ant-dev recently about lifecycles of
> tasks (there isnt a stable one) or of datatypes (there is none at all)
>
> ...if we allowed datatypes to implement an execute() interface, after
> they are configured (but before they are passed to tasks), they could do
> some work -such as retrieve an artifact or list of artifacts from a
> remote repo.
>
> We could then have a resource which did the resolution at the place of
> use:
>
>
> <taskdef uri="antlib://org.example.x">
>     <ivy:path conf="example" />
> </taskdef>
>
> Alternatively, you'd have an <ivy:antlib> task that declared where an
> antlib came from
>
> <ivy:antlib uri="antlib://org.example.x" conf="example" />
>
> 2. I think we need a version of <subant> that takes a graph (not a
> list), and when one sub build fails, skip all its dependencies, but do
> the others. This ensures that when a build breaks, you can get by with
> the ones that still work. At the end of the build you still halt with a
> failure, but now you can report '8 children failed, 13 skipped' instead
> of just stopping on the first problem, which may not be the most
> important one.


This sound like good ideas! I would love to see this kind of things in
Ant+Ivy :-)

- Xavier

Re: Ivy + Gump

[Steve Loughran <st...@apache.org>]

Gilles Scokart wrote:
> The sky is the limit... 
> 
> Who never had issues to find/download/install the correct list of
> dependencies of an antlib?  Or even find the set of antlibs required by a
> build script?
> 

possible changes:
1. There was some discussion on ant-dev recently about lifecycles of 
tasks (there isnt a stable one) or of datatypes (there is none at all)

...if we allowed datatypes to implement an execute() interface, after 
they are configured (but before they are passed to tasks), they could do 
some work -such as retrieve an artifact or list of artifacts from a 
remote repo.

We could then have a resource which did the resolution at the place of use:


<taskdef uri="antlib://org.example.x">
    <ivy:path conf="example" />
</taskdef>

Alternatively, you'd have an <ivy:antlib> task that declared where an 
antlib came from

<ivy:antlib uri="antlib://org.example.x" conf="example" />

2. I think we need a version of <subant> that takes a graph (not a 
list), and when one sub build fails, skip all its dependencies, but do 
the others. This ensures that when a build breaks, you can get by with 
the ones that still work. At the end of the build you still halt with a 
failure, but now you can report '8 children failed, 13 skipped' instead 
of just stopping on the first problem, which may not be the most 
important one.

RE: Ivy + Gump

[Gilles Scokart <gs...@gmail.com>]

The sky is the limit... 

Who never had issues to find/download/install the correct list of
dependencies of an antlib?  Or even find the set of antlibs required by a
build script?

:)

Gilles

> -----Original Message-----
> From: Steve Loughran [mailto:stevel@apache.org]
> Sent: vendredi 23 mars 2007 11:09
> To: ivy-user@incubator.apache.org
> Subject: Re: Ivy + Gump
> 
> Jan.Materne@rzf.fin-nrw.de wrote:
> > I think about the following:
> > - use Ivy for handling the dependencies of the projects
> >   --> these specifies the versions they trust
> > - use Gump for integration builds
> >   --> check if there are incompatibilities
> >
> > Is there a way to share the dependency information?
> >
> >
> > Jan
> >
> 
> hey, you're on the slipperly slopes of mavenness there :)
> 
> Next you'll be wanting izpack to include the JARs(*), or your app server
> to read the pom to build a list of things that should be on the EAR
> classpath...
> 
> There is some stuff a colleague wrote to convert .pom files to RDF; its
> up at MIT's simile project now, I think. We can do the same with Ivy
> metadata too -convert it into a build-tool neutral format. Stefano
> Mazzochi has apparently been thinking of some    RDF-driven gump
> successor which could use this.
> 
> For now, Gump and ivy are independent  -my projects are the only users
> of the ivy build, and while they dont actually get their classpath set
> up by it, they do use it for publishing and retrieving things, and for
> regression testing ivy itself.
> 
> -steve
> 
> (*) Once I've got this working I'll write it up on antbook.org. I'm
> retrieving every config into a separate dir,
> 
> http://svn.sourceforge.net/viewvc/smartfrog/trunk/core/release/build.xml?v
> iew=markup
> then feeding this into izpack -every package you can choose to install
> comes with its own ivy config
> 
> http://svn.sourceforge.net/viewvc/smartfrog/trunk/core/release/izpack/smar
> tfrog-install.xml?view=markup
> 
> 

Re: Ivy + Gump

[Steve Loughran <st...@apache.org>]

Jan.Materne@rzf.fin-nrw.de wrote:
> I think about the following:
> - use Ivy for handling the dependencies of the projects
>   --> these specifies the versions they trust
> - use Gump for integration builds
>   --> check if there are incompatibilities
> 
> Is there a way to share the dependency information?
> 
> 
> Jan
> 

hey, you're on the slipperly slopes of mavenness there :)

Next you'll be wanting izpack to include the JARs(*), or your app server 
to read the pom to build a list of things that should be on the EAR 
classpath...

There is some stuff a colleague wrote to convert .pom files to RDF; its 
up at MIT's simile project now, I think. We can do the same with Ivy 
metadata too -convert it into a build-tool neutral format. Stefano 
Mazzochi has apparently been thinking of some    RDF-driven gump 
successor which could use this.

For now, Gump and ivy are independent  -my projects are the only users 
of the ivy build, and while they dont actually get their classpath set 
up by it, they do use it for publishing and retrieving things, and for 
regression testing ivy itself.

-steve

(*) Once I've got this working I'll write it up on antbook.org. I'm 
retrieving every config into a separate dir,
 
http://svn.sourceforge.net/viewvc/smartfrog/trunk/core/release/build.xml?view=markup
then feeding this into izpack -every package you can choose to install 
comes with its own ivy config
 
http://svn.sourceforge.net/viewvc/smartfrog/trunk/core/release/izpack/smartfrog-install.xml?view=markup