search

ops4j / org.ops4j.pax.construct

Build, manage and deploy many types of OSGi bundles
https://ops4j1.jira.com/wiki/display/paxconstruct/Pax+Construct
24 stars 14 forks source link

pax:wrap could add same naming scheme as com.springsource uses when wrapping. [PAXCONSTRUCT-120] #132

Closed ops4j-issues closed 15 years ago

ops4j-issues commented 15 years ago

Anders Storsveen created PAXCONSTRUCT-120

A good naming scheme which com.springsource uses (which already has a substantial repo of wrapped artifacts) is to keep the same groupId, and adding com.springsource before the <groupId>.<artifactId>.

Example:
The package with groupId org.apache.xmlbeans and artifactId xmlbeans

would be wrapped:

groupid: org.apache.xmlbeans
artifactid: <yourgroupId>org.apache.xmlbeans.xmlbeans

There should at least be a good convention for this, that keeps the same groupId.
Any comments?

Votes: 0, Watches: 0

ops4j-issues commented 15 years ago

Stuart McCulloch commented

By default the pax-wrap archetype will use the containing module pom (ie. from the directory above) to compute the wrapper bundle's groupId, so if you use pax-wrap beneath org.foo:bar then the new groupId for the wrapped bundle is org.foo.bar - if there's no parent then it uses "examples" as the groupId.

You can also force it to use a specific groupId (http://www.ops4j.org/projects/pax/construct/help/wrap-jar.html)

-DbundleGroupId=groupId provide a customized groupId to the new bundle

The artifactId is computed by combining the original groupId and artifactId - this is done so we can wrap multiple artifacts under the same directory and maintain their inter-dependencies (see the wrapTransitive option) without worrying about any future clashes.

The reason we don't keep the original groupId by default is because only the original project is allowed to deploy artifacts under that groupId, in fact the SpringSource naming convention has caused a lot of confusion on the Maven mailing lists because it keeps the same groupId.