On Wed, Nov 24, 2010 at 3:52 PM, Ivo Ladage-van Doorn
<Ivo.Ladage-vanDoorn at gxsoftware.com> wrote:
> 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.
Yes, I think the subproject root pom should set the groupId
(namespace) for that subproject (eg. org.amdatu.cassandra) so this is
consistent and can be inherited by the modules so it does not have to
be set in each module as is the current situation.
> 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.
Nice! I overlooked the fact that indeed finalName is already set to
groupId.artifactId globally from the root pom. This in combination
with the namingTemplate option of the eclipse plugin voids most (all?)
of concerns which is mainly that everything should work "out of the
box". I'll add a improvement issue to add trhis to our root pom:
<plugin>
<artifactId>maven-eclipse-plugin</artifactId>
<configuration>
<projectNameTemplate>[groupId].[artifactId]</projectNameTemplate>
</configuration>
</plugin>
> 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.
In principle I agree as long as see argument above. Conventions are
good as long as they do not create barriers for new developers. My
personal experience with open source projects I check out and that do
not build / work / load in my IDE the first try around is.. well
limited.. because if they dont I delete and move on :),
> 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).
Not sure yet... I do not like the repeat... I do not like meaningless names..
Regards
Bram