cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: maven dependency issues
Date Sat, 26 Dec 2009 13:06:59 GMT

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






Mime
View raw message