gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <mcconn...@apache.org>
Subject RE: [status] main issues
Date Thu, 07 Oct 2004 18:04:31 GMT


> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]


> But the *most* serious concern is that we seem to have no way to build

> with Maven and, due to excalibur, this is holding up basically 15 
> percent of our projects (including, yes, you guessed right, cocoon).

Fast track solution could be to put the last released jar files into an
excalibur-releases module with project ids matching the current set of
ids, and disable the existing excalibur descriptors pending resolution
of gump/maven equation (see below).

> The problem with maven is that I don't know how we can "inject" the 
> gump-generated dependency jars into maven.

Maven is fine on the "injection" stuff - basically it used a jar
override property that tells maven to use the jar file named in a
property value as the actual jar to bind against.  The problem is the
generation of the property files (by gump's maven builder).

> Does anybody have an idea?

Gump uses a namespace made of a project id and an optional output key.
Maven uses a combination of group and artifact name combination.  If we
take for example - the jar file produced by ant containing the junit
optional task is referenced in gump as:

   project: ant
   id: junit

In Maven the same jar file is normally referenced as:

   groupId: ant
   artifactId: ant-junit

When Gump's maven builder generates the proprieties file used during the
maven build, it uses the gump project model to establish the set of
dependencies and for each dump declared dependency (with full
inheritance of dependencies) create a property with the following name
and value:

maven.jar.junit=/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.
jar

Problem here is that:

  1. this property definition does not correspond to anything 
     declared in the target project's project.xml (because the 
     property is derived from the gump based dependencies - not
     the project's declared dependencies)

  2. the strategy for mapping of gump artifact keys to maven 
     artifact keys is basically broken in that duplicate property
     names can be generated (e.g. the property name generated for 
     the main JUnit project jar file is "maven.jar.junit")

The solution to this problem is to drive the property file generation
off the project.xml file and NOT the gump dependency graph. This will
solve most issues because it will result in a much smaller set of
properties - but an underlying problem needs to be solved - namely the
declaration within a maven project of any mappings between maven
artifact names to gump project keys (e.g. ant/ant-junit --> ant:junit).
These mappings need to be used by the maven gump task when generating a
maven project descriptor.

Stephen.

> we can't expect excalibur to fix this on
> their own since this is obviously a gump issue, more than an excalibur

> issue.
> 
> --
> Stefano.
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message