Regardless of the convention used we will need to ensure that certain information is captured e.g. domain (jboss) and a finer grained notion of where an artifact comes from (jbossha.jar is associated with cluster).
Looking at how other projects have been structured there is no set notation for the naming.
What makes the most sense to me would be to have a package like schema for the group id which consists of the domain as well as an identifier which identifies the sub component. This schema allows the for the most flexibility in naming practices.
Some examples of this look like:
The rule would be that all projects begin with the org.jboss domain. The next portion would be the component identifier. If the projects were further subdivided after that the domain would be appended to accordingly.
Our artifact naming is not currently consistent. Many of the artifacts prepend jboss to their names (jboss-transaction). I would suggest we follow this schema for artifact naming as well.
The rule in this case would be jboss-identifier-classifier.jar. Identifier is the logical name of the jar and the classifier (if necessary) would be the type of jar (e.g. client, sources).
The package/domain name groupId seems fine and intersects with a recent discussion of defining a proper subtree of the org.dod.internet.private.enterprise.jboss OID namespace, and these conventions should be aligned.
In terms of the artifactId, I still need to understand what can be done in a maven repository vs jbossbuild. Currently I am using the multiple artifact per jbossbuild repository component to incorporate jars, sars, deployment descriptors into the jems installer.
If this has to be collapsed into an installer bundle artifact, then is there a custom plugin we can write that ties together the build, deployment and use of such an artifact in a consistent way? Having to unzip a repository artifact explictly in the build script as I am currently doing indicates a broken build lifecycle.