Stephen,
thanks much for your input. Some comments below.
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).
Yes, that might be an ad-hoc solution and it might work for now since there are not so many maven projects in our tree anyway (just checked).
Can you provide such a 'fake' descriptor? i think it would be much faster than me trying to hack one up.
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).
Ok, good to know.
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.
I'm sorry, but I have lost you.
If the strategy is broken, why don't we fix it? [but I think I'm missing a point here obviously]
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
