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). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041394#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...