On Dec 26, 2009, at 1:43 PM, Aristedes Maniatis wrote:
I don't understand that. If we only had one group id, there wouldn't be any 'odd' group ids. But I don't understand what a maven group id actually represents: it looks a bit like a namespace, in which case we really should only have one namespace for the whole project.
Group ID is a namespace. However another one of Maven (optional) conventions is to match it with the folder structure. I.e. if our root group is "org.apache.cayenne" then everything in the "framework" folder should have "org.apache.cayenne.framework" group ID.
There doesn't seem to be anything wrong with the current folder structure.
The only thing that appears bent to me is mixing "public" and "unpublished" modules in one place.
Only that the modules inside the framework folder should reference a parent which is the framework pom itself. And the names of each module should match exactly the folder names. If we did just that, would anything break?
The issue with parent is dependency resolving. If a user project includes dependency on cayenne-server, this would try to load its parent during the build. So if we have two levels of parents, we have more garbage for people to download (and us to maintain). Ideally public artifacts should be parent-less (kind of like the new tutorial project).
That plugin just seems too odd. And one day it would be nice to be able to release out of Hudson. That is, to ensure the build environment is always reproducible, just pick an artifact Hudson builds and name it with a release version. That's what we've been doing at my company and it helps a lot.
Just did a quick check using "mvn release:prepare -DdryRun=true" on the 3.0 branch. It doesn't do any magic. Same thing that we do with shell : "find . -name pom.xml |xargs perl -i -n -e 's/X-SNAPSHOT/X.X/; print;'" ... The only difference is snapsot versioning. We always use 3.0-SNAPSHOT and don't change between milestones. maven-release-plugin increments it. So snapshots go as 3.0B1-SNAPSHOT, 3.0B2-SNAPSHOT, 3.0B3-SNAPSHOT, etc.., which actually makes more sense and we can adopt this numbering scheme as well.
Now cutting release from Hudson could be more tricky. There are a few issues that makes it not practical: gpg signing (you don't want a committer private key sitting on a shared box), platform specific builds.
Andrus
