aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holly Cummins <holly.k.cumm...@googlemail.com>
Subject Re: Top down build of trunk failing during release process (was: Re: [VOTE] Release Apache Aries Parent 2.0.0)
Date Tue, 01 Jul 2014 18:15:33 GMT
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 <tjwatson@us.ibm.com> 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 <gnodet@apache.org>
> To:	dev@aries.apache.org
> 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 <holly.k.cummins@googlemail.com>:
> 
> > 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 <
> > david.bosschaert@gmail.com
> > > 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 <dkulp@apache.org> 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 <jpjhughes@gmail.com>
> > 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 <tjwatson@us.ibm.com> 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 <gnodet@apache.org>
> > > >>> To: dev@aries.apache.org
> > > >>> 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
> > > > dkulp@apache.org - http://dankulp.com/blog
> > > > Talend Community Coder - http://coders.talend.com
> > > >
> > >
> >
> 

Mime
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message