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
>
>

Reply via email to