> Maybe the Gump plugin needs an update, or Niclas used an old version,
> dunno.

There's only been one version with the maven tag.

I've just discovered
http://cvs.apache.org/viewcvs.cgi/maven-plugins/gump/src/plugin-resources/maven2gump.properties
 which apparently maps ids to gump ids.

Among other things, things like:
ant=jakarta-ant

Hmm... I had no idea that was there. Not exactly an elegant way to
maintain a list.

I'll get rid of it and cut a new version of the plugin.
Are there any still needing mapping that need be kept?

> I currently feel that we may be forced to declare artifact and group
> id individually on the jars we create, at least optionally.

I think this is a better way to do any compatibility mapping, if
possible. For example, it would help in doing what you mentioned next:

> Really difficult situations arise when projects get split
> (jakarta-slide used to contain slide-webdavclient which has now become
> a separate project in Gump) or artifacts get split.  This will be a
> problem to deal with since Gump living on the edge will have to follow
> such moves immediately while Maven project files can't be adapted
> without SNAPSHOTs being available IIUC.

the options for this seem to be:
- maintain the old one as a link to the new one in some way
- fork the gump descriptor - old points to old code, new to new (not a
migration really)
- keep project same, but map projects to group/artifact Ids that can change

I'm sure you guys already handle this and know the best option to take.

Cheers,
Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to