I think it's a little bit strange that on one hand we are branching of 0.0.6, use release candidates and even voting for the final release but on the other hand anyone can drop any code at any time in the trunk, which may or may not become (depending on the moment 0.0.6 is branched off) part of the 0.0.6 svn tree. I reckon that it's not in the reactor build so it can't (shouldn't) effect any build or release. So we could agree on that this is allowed if and only if the committed stuff is not in the reactor build.
BTW, it's not that I have restless nights because of it, just having some doubts ;-> Regards, Ivo -----Original Message----- From: amdatu-developers-bounces at amdatu.org [mailto:[email protected]] On Behalf Of Bram de Kruijff Sent: dinsdag 30 november 2010 10:42 To: amdatu-developers at amdatu.org Subject: Re: [Amdatu-developers] Artifact naming conventions > What do you think? I thought we agreed that at this point it does not matter so much? Note that it is not in the reactor, so it want (break the) build. If you consider 0.0.6 in code freeze I guess we should branch that. I do not want to hold back code on my local drive for obvious reasons... However, I can create a sandbox if it makes you feel better :) Regards, Bram > -----Original Message----- > From: amdatu-developers-bounces at amdatu.org [mailto:amdatu-developers- > bounces at amdatu.org] On Behalf Of Ivo Ladage-van Doorn > Sent: dinsdag 30 november 2010 10:11 > To: amdatu-developers at amdatu.org > Subject: Re: [Amdatu-developers] Artifact naming conventions > > 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:amdatu-developers- > bounces at amdatu.org] 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 > > _______________________________________________ > Amdatu-developers mailing list > Amdatu-developers at amdatu.org > http://lists.amdatu.org/mailman/listinfo/amdatu-developers _______________________________________________ Amdatu-developers mailing list Amdatu-developers at amdatu.org http://lists.amdatu.org/mailman/listinfo/amdatu-developers
