3 Replies Latest reply on May 4, 2006 10:58 AM by starksm64

    Maven repository conventions

    starksm64
    starksm64 May 3, 2006 11:46 AM

      We need to define the groupId/artifactId conventions. We have to consider that we will have:

      * very fine grained artifacts like common library jars
      * server integration jars, intermeadiate artifacts like sars
      * to be determined artifacts like a service/component bundle that is incorporated into an installer profile (could be the jems installer, ide installer/update thing, testsuite configuration maven plugin) that includes multiple elements according to some standardized canonical structure that includes libs, deployments, docs, etc.
      * distribution artifacts like jbossas. I'm not sure a thing should be the complete dist in the sense of a sourceforge type of download. Rather it should be a canonical dist along the lines of the previous component bundle as this is just another component that aggregates others.

      • 11028 Views
      • Tags:
        • 1. Re: Maven repository conventions
          ruel.loehr May 3, 2006 3:47 PM (in response to starksm64)

          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:

          org.jboss.server
          org.jboss.server.cluster
          org.jboss.server.dist
          org.jboss.server.installer
          org.jboss.server.installer.bundles
          org.jboss.jbpm
          org jboss.cache

          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).


            • Actions
          • 2. Re: Maven repository conventions
            starksm64
            starksm64 May 4, 2006 10:35 AM (in response to starksm64)

            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.

              • Actions
            • 3. Re: Maven repository conventions
              starksm64
              starksm64 May 4, 2006 10:58 AM (in response to starksm64)

              Here is the start of the oid wiki page.
              http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossOIDs

                • Actions