This is perhaps where my point about over-use of the snapshot dependencies and the versioning applies. For example, does blueprint core now need parser-1.2.1 rather than parser-1.2.0 to function correctly?
> On 1 Jul 2014, at 15:13, Thomas Watson <[email protected]> wrote: > > But that is not enough because there are other dependencies on artifacts that > are not publically available yet. For example, I still get this error > building blueprint out of trunk: > > [ERROR] Failed to execute goal on project org.apache.aries.blueprint.core: > Could not resolve dependencies for project > org.apache.aries.blueprint:org.apache.aries.blueprint.core:bundle:1.4.2-SNAPSHOT: > The following artifacts could not be resolved: > org.apache.aries.blueprint:blueprint-parser:jar:1.2.1, > org.apache.aries.proxy:org.apache.aries.proxy.impl:jar:1.0.3: Could not find > artifact org.apache.aries.blueprint:blueprint-parser:jar:1.2.1 in EclipseLink > Repo (http://download.eclipse.org/rt/eclipselink/maven.repo/) -> [Help 1] > > That is why I was asking if we can temporarily use a staging maven repo for > the artifacts that are under review to be released. I don't think updating > all the references to use the next SNAPSHOT version is correct. Right after > the release we would then go back to change them back to reference the real > release? > > Tom > > > > Guillaume Nodet ---07/01/2014 03:51:56 AM---Again, deployment of a snapshot > is not the issue here. The problem is that artifacts being released > > From: Guillaume Nodet <[email protected]> > To: [email protected] > Date: 07/01/2014 03:51 AM > Subject: Re: Top down build of trunk failing during release process > (was: Re: [VOTE] Release Apache Aries Parent 2.0.0) > > > > Again, deployment of a snapshot is not the issue here. > The problem is that artifacts being released use the parent 2.0.0 which is > not publicly available yet. > Anyway, I've moved those bundles to use parent 2.0.1-SNAPSHOT so everything > should be sorted. > > > 2014-07-01 10:45 GMT+02:00 Holly Cummins <[email protected]>: > > > Our release instructions also include the deployment step: > > http://aries.apache.org/development/releasingaries.html > > > > In the discussion of the release strategy (incremental vs trunk-breaking) > > they don't include the detail about preferring to depend on releases, which > > might be worth adding. > > > > Holly > > > > > > On Tue, Jul 1, 2014 at 8:36 AM, David Bosschaert < > > [email protected] > > > wrote: > > > > > Yep - the Felix release process outlines this deployment of a snapshot > > > just before doing the actual release. I think it would make sense for > > > Aries to follow that too: > > > > > > > > http://felix.apache.org/documentation/development/release-management-nexus.html > > > > > > David > > > > > > On 30 June 2014 22:27, Daniel Kulp <[email protected]> wrote: > > > > > > > > The normal process would be to immediately upon building the “release”, > > > do a deploy of the new snapshot version and update everything that > > > references the old snapshot to the new snapshot. Thus, things would > > > continue to build. > > > > > > > > Dan > > > > > > > > > > > > On Jun 30, 2014, at 4:51 PM, Jeremy Hughes <[email protected]> > > wrote: > > > > > > > >> After the release candidate artifacts are posted, module poms have > > their > > > >> version bumped up. So parent is now 2.0.1-SNAPSHOT. Modules that are > > > being > > > >> released at the same time were depending on 2.0.0-SNAPSHOT and moved > > to > > > >> depend on 2.0.0 as part of their own release process. Which is fine > > for > > > >> reviewing the release artifacts of all those modules together. > > However, > > > the > > > >> part of the release process that bumps a module's version in trunk > > > >> subsequent to the tagging, doesn't bump the dependency versions. They > > > >> shouldn't: a) there's no reason to depend on snapshot b) it doesn't > > know > > > >> the module it depends on is being released at the same time and > > > therefore > > > >> isn't available in a repository. > > > >> > > > >> Our process for releasing modules together that have dependencies > > > between > > > >> them, is causing the trunk build to be broken while the release vote > > is > > > >> ongoing. I'm not sure what other multi-module projects do and why > > we're > > > >> different, but surely they don't all suffer from this. > > > >> > > > >> Any ideas? > > > >> > > > >> > > > >> On 30 June 2014 19:53, Thomas Watson <[email protected]> wrote: > > > >> > > > >>> I'm new here and this may be obvious to others. While we are in > > > release > > > >>> mode, is it expected that trunk will no longer build due to > > references > > > to > > > >>> the unreleased 2.0.0 parent pom? Is there a good process to follow > > in > > > >>> order to be able to build everything locally while doing other work > > > that is > > > >>> not in the middle of being released? > > > >>> > > > >>> Tom > > > >>> > > > >>> > > > >>> > > > >>> [image: Inactive hide details for Guillaume Nodet ---06/30/2014 > > > 01:10:56 > > > >>> PM---This is the first release of a set. It contains the > > > paren]Guillaume > > > >>> Nodet ---06/30/2014 01:10:56 PM---This is the first release of a set. > > > It > > > >>> contains the parent pom in version 2.0.0 > > > >>> > > > >>> From: Guillaume Nodet <[email protected]> > > > >>> To: [email protected] > > > >>> Date: 06/30/2014 01:10 PM > > > >>> Subject: [VOTE] Release Apache Aries Parent 2.0.0 > > > >>> ------------------------------ > > > >>> > > > >>> > > > >>> > > > >>> This is the first release of a set. > > > >>> It contains the parent pom in version 2.0.0 > > > >>> > > > >>> Staging repository available at > > > >>> > > https://repository.apache.org/content/repositories/orgapachearies-1002 > > > >>> > > > >>> [ ] +1 Release parent 2.0.0 > > > >>> [ ] -1 Do not > > > >>> > > > >>> Cheers, > > > >>> Guillaume Nodet > > > >>> > > > >>> > > > > > > > > -- > > > > Daniel Kulp > > > > [email protected] - http://dankulp.com/blog > > > > Talend Community Coder - http://coders.talend.com > > > > > > > > > >
