RE: Maven and gump

[Brett Porter <bp...@f2network.com.au>]

> Historically it has been phase 1 and even succeeded at one 
> point. Currently Gump's inability to build dom4j or jaxen is 
> probably the biggest problem for getting Maven built.

I must have missed something... So gump can't use any JARs it doesn't build
itself?

> No problem with working from an installed Maven first, but 
> we'll have to ensure it gets maintained (i.e. updated with 
> each new milestone, RC).

Happy to help looking after that. One issue will be the plugins... We have
slated some work for 1.1 to clear up how different versions will interact,
but at the moment certain projects may need a variety of plugin versions.
They can specify dependencies to make sure they get used, but we might need
to make sure they get removed again so they don't interfere with other
projects.

> > Another (better?) alternative is to have Gump switch the 
> descriptor at 
> > build time via XSLT or something, so that all the dependencies it 
> > knows about use the version SNAPSHOT instead of the one specified.
> 
> How would that work?  I'm pretty ignorant about Maven.

SNAPSHOT is sort of the identifier for "latest build". So if gump were
building snapshots, Maven could use them. This is a very mavenish solution
though, because there'd need to be a way to create and deploy snapshots for
non-Maven projects (not difficult - just an appropriate move command).

> Can Gump say the SNAPSHOT is the jar I've just built there or 
> would that require SNAPSHOTS to be available in some 
> repository?  If the later is the case, it looks as if jar 
> overrides were the better option to me.

Yeah, at least for the being, I think you might be right. Jar overrides seem
to match the current model perfectly and are easy to set up.

Cheers,
Brett

Re: Maven and gump

["Adam R. B. Jack" <aj...@trysybase.com>]

Here is a bit of an update:

Ant comes with an ant.[sh|bat], but Gump calls it via it's Java classname
directly (org.apache.tools.ant.Main). I beleive that Gumpers would want this
for Maven, so the JDK/bootclasspath/JVM arguments (etc) are all controlled &
not in debate. I've looked into the maven script and it looks similar to the
Ant one, the main difference is [perhaps] the use of Forehead.

I see that forehead is for managing the classloader hierarchy, so is it
installed classloaders before running Maven? Since Maven is (I'm guessing
here) using classworlds for classloader management (artifact version
management?) but Gump is setting the CLASSPATH(s) I'm hoping that the
difference will be transparent to the build. [Brett, can you confirm?
Testing will also help us here.]

A command line would be along the lines of:

    java -Djava.awt.headless=true
org.apache.maven.cli.App --offline -Dbuild.sysclasspath=only {goal}

Here is a sample build.properties: [belt and braces w/ build.sysclasspath,
jsut testing.]

# ------------------------------------------------------------------------
# Gump generated properties file
# ------------------------------------------------------------------------
build.sysclasspath=only

# ------------------------------------------------------------------------
# M A V E N  J A R  O V E R R I D E
# ------------------------------------------------------------------------
maven.jar.override = on

# ------------------------------------------------------------------------
# Jars set explicity by path.
# ------------------------------------------------------------------------
maven.jar.output4=F:\data\OSS\jakarta-gump\python\test\gump\module4\dist\lib
\out
put4.jar
maven.jar.output1=F:\data\OSS\jakarta-gump\python\test\gump\module1\dist
\lib\output1.jar

regards,

Adam

Re: Maven and gump

[Stefan Bodewig <bo...@apache.org>]

On Thu, 27 Nov 2003, Brett Porter <bp...@f2network.com.au> wrote:

>> Historically it has been phase 1 and even succeeded at one 
>> point. Currently Gump's inability to build dom4j or jaxen is 
>> probably the biggest problem for getting Maven built.
> 
> I must have missed something... So gump can't use any JARs it
> doesn't build itself?

Uhm, no.  But in order to follow Gump main goal - be an early
indicator for backwards incompatible changes - it wants to.

Current CVS HEAD of dom4j doesn't compile against any released version
of jaxen - and current CVS HEAD of jaxen doesn't compile against the
latest JDOM.

So, in order to build a project that depends on jaxen or dom4j, those
projects have to depend on "packaged" versions of either.  packaged
means that it is some installed jar of a released version.  "packaged"
jaxen and dom4j jars are available but not heavily used ATM.

> One issue will be the plugins... We have slated some work for 1.1 to
> clear up how different versions will interact, but at the moment
> certain projects may need a variety of plugin versions.

In the spirit of Gump all those projects would always see the very
latest version of each plugin.  Again, to detect backwards
incompatible changes (or to push the depending project to stop using
deprecated stuff, of course).

The alternative would be to have separate Gump packages for those
different versions and make the projects each depend on a specific
package.

> SNAPSHOT is sort of the identifier for "latest build". So if gump
> were building snapshots, Maven could use them.

It does (and does so for non-Maven projects), see
<http://gump.covalent.net/jars/latest/>.  It may not follow a
directory layout usable by Maven, though.

Stefan

Re: Maven and gump

["Adam R. B. Jack" <aj...@trysybase.com>]

> > Historically it has been phase 1 and even succeeded at one
> > point. Currently Gump's inability to build dom4j or jaxen is
> > probably the biggest problem for getting Maven built.
>
> I must have missed something... So gump can't use any JARs it doesn't
build
> itself?

Not sure it is a matter of "can't". Gump would prefer to build everything
from source control, but it can use pre-built jars (installed packages, jars
in  project's work). That said, those two have a (disappointing) circular
dependency that we are hoping they'll fix sometime soon. I think Stefan was
saying that without that fix, a complete Maven build would not be possible.

I'd really like to build Maven from the ground up, seems the most Gump-like.

> Happy to help looking after that. One issue will be the plugins... We have
> slated some work for 1.1 to clear up how different versions will interact,
> but at the moment certain projects may need a variety of plugin versions.
> They can specify dependencies to make sure they get used, but we might
need
> to make sure they get removed again so they don't interfere with other
> projects.

As we get more Gumps (or remote hardware) this could become an issue, but we
can work on that if/when it becomes a scaling issue.

> Yeah, at least for the being, I think you might be right. Jar overrides
seem
> to match the current model perfectly and are easy to set up.

Could you do us a favour and document:

1) The command line (e.g. "maven .... ")
    Include:
1.1) how to set properties,
1.2) override ant properties [if needed]
1.3) how to do 'jar overrides'
2) The working directory
3) The exit codes/outputs/etc.

As for metadata, since Gump is goign to try to overide the POM (which I
suspect will be in CVS) I'd like *NOT* to try to have Gump read a POM for a
phase 1 implementation. Personally, I'd like to see there be a <maven entry
similar to the <ant one today: http://jakarta.apache.org/gump/ant.html

One other thought, what say Maven generates a gump descriptor with two
projects (for each one it has today). One normal ant [as now], and one with
a <maven build element. That was we can see the practicality/stability of
the latter w/o interrupting Gumping for the projects.

regards,

Adam