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
This archive was generated by hypermail 2.0.0 : Sat Dec 26 2009 - 08:07:35 EST