I'm currently minded to go for the CXF style - one trunk, multi-module,
single-version, everything checked out to work on it.
But for the parent, the Jenkins issues and per-module CI (which I like),
a fixed (not <relativePath>) parent POM version makes sense. It also
means anyone can work on an individual module as well.
For the developers, the choice may not matter so much as several schemes
work. Eclipse isn't affected (?).
Much of this is making is as easy and approachable for people working
with the source on a bit of the system, and does not affect us directly
once the choice is made.
(Still haven't completely grokked why SNAPSHOT versions can't pull down
SNAPSHOT parent POMs but life is too short.)
Andy
On 19/12/11 18:16, Benson Margulies wrote:
I've maybe skipped a step in explanation.
On the one hand, look at something like CXF. It's a big monolith. It's
all release at once from one svn tree. There's a parent at the top,
and the version of the parent is the same as the version of everything
else. In between release, everything has the same version.
On the other hand, look at https://svn.apache.org/repos/asf/maven/plugins/trunk.
The parent, in the maven-plugins subdir, is released independently
from the plugins. In svn, the individual plugin poms always name a
RELEASED version of the parent. When someone wants to change the
parent, he or she changes it and then releases it -- and then changes
individual plugins to use it.
That's the model I'm proposing for you.
The settings.xml/repository change is a way to also permit a single
release vote on the parent and (one or more) of the users of the
parent.
On Mon, Dec 19, 2011 at 12:54 PM, Andy Seaborne<a...@apache.org> wrote:
So is it because it's a SNAPSHOT ebe when building a SNAPSHOT? Using the
"staged" item works so it seems to be SNAPSHOT specific. That hadn't
occurred to me.
(Setting a special things in settings.xml does not help users.)
Oh well - It'll clearup when/if we get the release promoted. Until then,
svn is a bit hit or miss.
Andy
On 19/12/11 17:40, Benson Margulies wrote:
Other projects I work always refer to released versions of parent poms.
So, their cycle is:
- from time to time, release the parent.
- after a parent release, update users of the parent.
At Maven, I just set up a mechanism for combining these. Infra will,
if you like, create a repository group for all of the jena staging
repos. Then, jena devs can put that repo into their settings.xml
files. Then you can stage a release of a new parent, modify children
to use it, and then stage a release of the children.
Either way, the only time someone sees a pom that says 1-SNAPSHOT is
ephemerally when they are making a change to that pom and
debugging/testing it.
On Mon, Dec 19, 2011 at 12:31 PM, Andy Seaborne<a...@apache.org> wrote:
One of the problems with both the Jenkins setup and with resetting after
the
release build has been with the parent POM.
After "svn update" all the modules, dependency resolution isn't causing
the
new 1-incubating-SNAPSHOT POM to be pulled in. How should the parent POM
get
placed in the repo?
(relativePath assumes available in the file system).
https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ParentPOMResolution
The only solution I have found is to "mvn install" it which seems to be
missing the point.
Is this broken for other people as well?
How can I get the new parent POM pulled into the local repo without
checking
JenaTop out?
Jenkins jobs seem to be failing when run on a server where jena-top is
not
available.
Andy
