Maven project naming conventions

[pgier]

Looking at the snapshots repository, I can imagine the root jboss folder
http://snapshots.jboss.org/maven2/jboss getting large very quickly. Possibly to the point where it is difficult to navigate.

Would it be beneficial to change the naming conventions to group smaller projects together similar to their structure in svn?
For example, instead of the current flat structure common could be grouped like this within the jboss directory:

/common
/common/jboss-common-core
/common/jboss-common-logging-jdk
/common/jboss-common-logging-log4j
/common/jboss-common-logging-spi
/common/jboss-common-xb

This way the actual artifact names would still be unique as long as we keep the path in the artifact name.

The javaee project could have a structure like this:

/javaee/jboss-javaee-ejb-api
/javaee/jboss-javaee-jacc-api
/javaee/jboss-javaee-jad-api
etc...

This structure would map a little better to our svn structure, and I think it would be a little easier to navigate.

[starksm64]

That might be fine for a jboss repository, but it is likely problematic if we export this to other public repos such as a fedora maven2 repo. A group like common is simply too common a name.

[pgier]

I was thinking that it would still be under the jboss folder.
So the groupId would be jboss.common and the artifactId would be jboss-common-core, jboss-common-logging-spi, etc..

So you would never refer to common by itself. Same thing for javaee, it would have a groupId of jboss.javaee, or something similar.

[starksm64]

Ok, I see. The reason we flattened the jboss group was to ensure that there was never a conflict with artifacts. I did not see much point to further organizing the contents as its not a navigation tree. If there is some other benefit aside from navigation via a web browser I'd like to hear it.

[pgier]

Here are the advantages I see:

1. The repository structure will more closely match the svn structure, so it will be a little easier to determine where the jars came from based on looking at the maven repository.

2. The maven team went from a flat repository structure in maven 1 to a more deep repository structure in maven 2 (http://maven.apache.org/guides/mini/guide-relocation.html)
I think their reasoning had more to do with preventing name conflicts between different organizations, but I think it would still be good to follow their conventions.

3. It is easier to do a smaller checkout of the repository with a deeper hierarchy. For example, if I want to deploy some artifact in the common project, I could just checkout the common directory without checking out the whole jboss directory.

4. The directory browsing issue also affects not just us, but also external users. We might solve the issue using something like archiva internally, but if we start syncing with the central maven repository, then external sites will have the browsing issue.

In regards to the possible naming conflict issue (the reason for making the structure flat), when building it should never be an issue, because the artfiacts will always be placed into their groupId directories. But for a project like microcontainer where we want to distribute a zip with packaged jars in a lib directory, I can see it possibly being a problem if we have two projects with the same artifact ID, and they both are placed directly in the lib directory.
One way we could deal with this is to include the groupId in the name of the file when we put jars into the lib directory. Another way is to put the files within their group directories within the lib directory (similar to a local repository).