3 Replies Latest reply on Jan 14, 2011 6:21 AM by burmanm

    Module artifact naming convention

    tfennelly

      At the moment we're naming all artifacts with <groupId>org.switchyard</groupId> e.g. for the core api:

       

      <groupId>org.switchyard</groupId>
      <artifactId>core-api</artifactId>
      

       

      For the components we were thinking of applying a prefix of "component-" to all the artifactIds e.g. for the bean component:

       

      <groupId>org.switchyard</groupId>
      <artifactId>component-bean</artifactId>
      

       

      So there's no real logical separation between the core and component artifacts.  In the maven repo they'd all be on the same level and the only way of telling the components apart would be from the prefix.  No big deal I suppose.

       

      We're also toying with the idea of using a sub-groupId of "components" for the components and dropping the prefix.  So the bean component would be:

       

      <groupId>org.switchyard.components</groupId>
      <artifactId>bean</artifactId>
      

       

      I personally prefer this because it highlights the grouping within the <groupId>, which seem more logic to me anyway.  It also means that the will be grouped physically in the maven repo in a sub-folder under switchyard called "components", which I think is nice too.

       

      Anyone have any major preferences here?

        • 1. Re: Module artifact naming convention
          tcunning

          It's kind of six of one, a half dozen of the other, but I think maintaining consistency in the groupId (i.e. org.switchyard) might be less confusing for the end user - especially if they are packaging up their ESB project using maven.

           

          I looked for some examples of how other projects do it - it seems like camel does things similarly to the first example you gave (org.apache.camel, camel-core and camel-spring).

          • 2. Module artifact naming convention
            kcbabo

            I should just say "I agree with Tom" and leave it at that. :-)

             

            Personally, I prefer the groupId approach.  Components are a distinct piece from the core - they have a distinct parent pom, their own repository, etc.  Just makes sense from an organization standpoint to have a groupId specific for components.

            • 3. Module artifact naming convention
              burmanm

              I'd go with Keith on this one and use the groupId approach also, "component-bean" sounds like using one directory to store all files.