You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Stefan Bodewig <bo...@apache.org> on 2004/03/31 09:28:15 UTC
Maven support - the ids
Hi,
IIUC the current incubator-geronimo build fails since Maven project
names and Gump project names don't match. The Maven Gump plugin
already knows all the necessary transformations, so it would probably
wise to simply reuse
<http://cvs.apache.org/viewcvs.cgi/maven-plugins/gump/src/plugin-resources/maven2gump.properties>
in Gump's Maven integration part.
Note that the file above is out of date, in particular most of the
Avalon names don't work anymore, but some mappings like those for ant
or log4j are deprecated as well. I'll put together a patch for it
once the Avalon build system has become stable.
Cheers
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Maven support - the ids
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> I was under the (wrong) expression that Gumpy would parse Maven's
> project.xml instead of using a Gump descriptor and had difficulties to
> map the project names.
No, Gump has enough complex code for loading metadata, I'd really rather
rely upon the gump goal in maven & not introduce yet another XML element
called "<project" (of a different flavour.)
Also, we need to make more progress on seeing <maven builds (so I appreciate
you brining this up) before we invest more around the edges.
> > As I see it, the main issue is artefact ids for projects that Gump
> > builds (likely using ant) that do not have a Maven equivalent build,
> > so perhaps not 'artefact id' in Maven.
>
> Any idea how the Maven Gump plugin deals with it? I'd assume it will
> simply make the project depend on the pther project without specifying
> any ids - and thus get all the jars.
Actually, no idea. :(
Reading:
http://maven.apache.org/reference/project-descriptor.html#dependencies
http://maven.apache.org/reference/project-descriptor.html#dependency
I suspect that groupId, artifactId,jar,type all play a role (and I see that
'id' is deprecated.) From these I can see that the 'gump' maven goal can
generate dependencies (groupId = Gump project) and ids.
Hopefully POM project descriptors specify all groupIds and artifactIds,
otherwise Gump can't use set the classpath overrides.
> But you need an id to specify the jat name override, right?
Correct.
> If this is a the problem, then we'll need Brett's help, I assume.
A Mavenite's insights would certainly help.
> How does the repository effort address this? Does it address this at
> all?
I think it does, but as a side effect. I think we (Apache/others) just come
to a consensus on group and artefact ids. I suspect we are far closer to
condenses than we realize, and we should just (all) work towards a common
set.
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Maven support - the ids
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 31 Mar 2004, Adam R. B. Jack <aj...@trysybase.com> wrote:
>> The Maven Gump plugin already knows all the necessary
>> transformations, so it would probably wise to simply reuse
>>
> <http://cvs.apache.org/viewcvs.cgi/maven-plugins/gump/src/plugin-resources/m
> aven2gump.properties>
>> in Gump's Maven integration part.
>
> Sorry, what are you suggesting?
I was under the (wrong) expression that Gumpy would parse Maven's
project.xml instead of using a Gump descriptor and had difficulties to
map the project names.
> As I see it, the main issue is artefact ids for projects that Gump
> builds (likely using ant) that do not have a Maven equivalent build,
> so perhaps not 'artefact id' in Maven.
Any idea how the Maven Gump plugin deals with it? I'd assume it will
simply make the project depend on the pther project without specifying
any ids - and thus get all the jars.
But you need an id to specify the jat name override, right?
If this is a the problem, then we'll need Brett's help, I assume.
How does the repository effort address this? Does it address this at
all?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Maven support - the ids
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> IIUC the current incubator-geronimo build fails since Maven project
> names and Gump project names don't match.
IIUC the issues is more (or also) that the 'artifact ids' (our jar ids) do
not match. Having the project names the same is an issue for dependency
determination, but for setting the classpath the Gump code generates a Maven
properties file and overrides by artifact id:
http://brutus.apache.org/gump/public/incubator-geronimo/gump_file/build.properties.html
[I'll fix the file type, a missing parameter...]
> The Maven Gump plugin
> already knows all the necessary transformations, so it would probably
> wise to simply reuse
>
<http://cvs.apache.org/viewcvs.cgi/maven-plugins/gump/src/plugin-resources/m
aven2gump.properties>
> in Gump's Maven integration part.
Sorry, what are you suggesting?
As I see it, the main issue is artefact ids for projects that Gump builds
(likely using ant) that do not have a Maven equivalent build, so perhaps not
'artefact id' in Maven. That said, this is a real world problem (not just a
Gump world problem) and so I have to assume the Maven builds
I believe that we'll want to pay more and more attention to artefact ids =
jar ids, so I am adding a peer page to this one, to show by id.
http://brutus.apache.org/gump/public/gump_xref/output_project.html
BTW: Right now 'outputs' (the table of jar with id) only shows if the
project is verbose or above (e.g. when it fails a few times, or the user
sets verbose|debug="true" in the descriptor). Do we need it visible more
often?
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org