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
