Hi Bram, The disadvantage of the current approach I think is repeating the groupId in the artifactid's of the root modules, as opposed to those of all other projects. Looking into the maven repository, the root artifact of a project will be located in a different directory then all its modules (i.e. org/amdatu/org.amdatu.authentication versus org/amdatu/authentication/oauth/client). This can easily be fixed by dropping the groupid prefix in the root pom's of subprojects. Regarding the Eclipse issues; the naming of projects is just a matter of configuration. If you define the naming template '[groupId]-[artifactId]' upon project import all your 'problems' are fixed. Same for naming of the final jar; this can be configured by setting the proper finalName (artifactId is the default, could be changed to groupId.artifactId) in the pom.
I like the fact that the package name is fixed and by definition equal to groupId.artifactId. Only the groupId and artifactId can be chosen, the rest is defined by convention (exported package, symbolic name, PID, etc. etc.). The less freedom the better when it comes to consistency. You could argue if we should repeat the groupid in the artifactid, as some projects do and other do not. I think repeating the groupid in the artifactid is redundant, which also will manifest itself in the maven repository. On the other hand, without the groupid an artifactid may be quite meaningless (like an artifactid 'application' with groupid org.amdatu.cassandra). I'm not sure what conventions you exactly propose, but I think we need to have a convention for naming of packages, symbolic name, final jar name, etc. etc. Just for consistency. Regards, Ivo -----Original Message----- From: amdatu-developers-bounces at amdatu.org [mailto:[email protected]] On Behalf Of Bram de Kruijff Sent: woensdag 24 november 2010 15:13 To: amdatu-developers at amdatu.org Subject: [Amdatu-developers] Artifact naming conventions Hi List, while moving Cassandra into its own subproject I'm noticing some IIMHO strange things in our naming conventions documented at http://www.amdatu.org/confluence/display/Amdatu/Internal+naming+conventions and how there turn out in the real world 1) It is documented that a subproject like "amdatu-cassandra" has groupId "org.amdatu" and artifactId "org.amdatu.cassandra" while each module like "Cassandra Application" within that subprojects has groupId "org.amdatu.cassandra" and artifactId "application". As a consequence the parent/root artifact has a different naming schemes and namespaces from the rest of the components (org.amdatu vs org.amdatu.cassandra) which is kind of awkward Eg. /org/amdatu/org.amdatu.cassandra/org.amdatu.cassandra-0.0.6-pom /org/amdatu/cassandra/application/application-0.0.6.pom 2) Also it is documented that the packagename for a module is equal to groupId concatenanted with artifactid. As packagenaming is restrictive in the use of characters like - by implicit definition now the artifactId is too. This leads to all kinds of awkwardness like -> The cassandra application gets a reasonable modulename "cassandra-application" but, as that does not fit the convention, the awkward (and non descriptive) artifactId "application". -> Loading a amdatu subproject into Eclipse you get a non descriptive project name like "service" -> Loading multiple amdatu subproject into Eclipse leads to name conflicts as for example we have multiple projects name "service" -> Simply looking at the list of artifacts we have multiple artifacts with final name "service-0.0.6-SNAPSHOT.jar" Suggesting we move to the following (maven) convention: 1) Each subproject root claims a module name like "amdatu-cassandra" and namespace "org.amdatu.cassandra" 2) Each subproject module claims a extended subname like "amdatu-cassandra-application" (used as module name and artifactId) and subnamespace "org.amdatu.cassandra.application" (used as groupId). With regard to the latter I wouldn't be too strict with regard to artifactId naming as I consider that more of a best practice. Eg. if you wanna drop the "amdatu-"prefix and use "cassandra-application" I wont loose any sleep over it. As long as a subproject keeps its own consistent namespace at runtime there is no problem, but an artifact name should be descriptive/informative nevertheless. This gives us (by convention / without additional configuration) descriptive project names, descriptive artifact names, clean namespace seperation for subprojects. Not sure if there is a drawback in there but I'd like your opnions and pros and cons. Regards, Bram _______________________________________________ Amdatu-developers mailing list Amdatu-developers at amdatu.org http://lists.amdatu.org/mailman/listinfo/amdatu-developers
