Hi Bram, I noticed that you committed changes for AMDATU-190, which was not planned for 0.0.6 and will not be finalized in 0.0.6. As a result, 0.0.6 will contain this proof of concept code. IMHO this should not have been committed to the trunk at this point for that reason. The changelog of 0.0.6 will not provide any information about this new code since the corresponding JIRA issue has not been resolved yet. The only clue is de readme.txt in the root of this project. I also have some proof of concept code for oAuth stuff locally, but am explicitly waiting for 0.0.6 to be branched off before I commit it. In general I would expect only code to be shipped in a release with a corresponding resolved JIRA issue. Otherwise each release may include an arbitrary set of undocumented and unfinished code. What do you think?
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 20:30 To: amdatu-developers at amdatu.org Subject: Re: [Amdatu-developers] Artifact naming conventions 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 _______________________________________________ Amdatu-developers mailing list Amdatu-developers at amdatu.org http://lists.amdatu.org/mailman/listinfo/amdatu-developers
