I agree that this should be true. However, I have yet to be able to
successfully build trunk (with itests included) in the current state
after having built all of the tags currently up for vote. I'm hitting
the timeout issue in the application itests with extreme consistency -
so much so that it is clear that it isn't just timing related.
Doing some more digging it appears that we have some inconsistencies in
how we reference versions in our tests. In this particular error it
seems that the test includes the 0.1-incubating version of
org.apache.aries.util bundle when running but the manifest for
org.apache.aries.application.utils (required by the
AriesApplicationManager which is the service we are waiting for when we
time-out) is importing the org.apache.aries.util package with a version
range of "[0.2.0,0.3.0)".
This version range is being set in the default-parent pom for all
projects which creates problems if we don't plan to release all
components together - so we will need to start overriding this setting.
Joe
On 4/13/10 4:58 AM, Jeremy Hughes wrote:
On 12 April 2010 23:37, David Jencks<[email protected]> wrote:
BTW I think you can alleviate the current build problems by checking out the
tags and building them yourself....
that's true, but each of the modules under tags will have to be built
separately. Under trunk we have
trunk
├── application
├── blueprint
├── eba-maven-plugin
├── jmx
├── jndi
├── jpa
├── parent
├── samples
├── samples-sandbox
├── spi-fly
├── subsystem
├── target
├── testsupport
├── transaction
├── tutorials
├── util
└── web
Under tags we have:
tags
├── application-0.1-incubating
├── blueprint-0.1-incubating
├── eba-maven-plugin-0.1-incubating
├── jmx-0.1-incubating
├── jndi-0.1-incubating
├── jpa-0.1-incubating
├── org.apache.aries.util-0.1-incubating
├── parent-0.1-incubating
├── samples-0.1-incubating
├── testsupport-0.1-incubating
├── transaction-0.1-incubating
└── web-0.1-incubating
without the convenience of the top level pom.
or, if you are voting, you will already have downloaded the source bundles and
built them to make sure they are buildable -- pretty much the closest thing to
a requirement for voting on an apache release.
thanks
david jencks
On Apr 12, 2010, at 3:32 PM, David Jencks wrote:
On Apr 12, 2010, at 2:08 PM, Jeremy Hughes wrote:
On 12 April 2010 21:19, Joe Bohn<[email protected]> wrote:
On 4/12/10 1:00 PM, Jeremy Hughes wrote:
On 12 April 2010 14:19, Joe Bohn<[email protected]> wrote:
All,
First off - Thanks to Jeremy for pulling together this release and doing
the
really hard work of sorting out the details the first release. I know
this
is a difficult and often frustrating effort.
This thread can server to discuss anything related to the vote.
A few comments/things to consider:
1) There were some manual changes necessary to update the version in
properties and a few other places. We might be able to remove some of
these
but I'm sure not all of them. However, it does create a problem because
we
now have to change them to the "real" version number before running the
maven-release-plugin but then that puts trunk in a dangerous state in
trunk.
Perhaps we should consider creating a branch before a release process
from
the branch. That way work on trunk to continue and the branch could
remain
with the hard coded versions (and basically frozen) until we ultimately
release and need to update the hard-coded versions to the next snapshot.
I'm not sure if that really solves all of the issues but it might be a
little better.
2) Because we didn't release every project we now have a mixture of
0.2-incubating-SNAPSHOT and 0.1-incubating-SNAPSHOT versions in trunk. I
wonder if we should bump all of trunk up to the next snapshot version to
keep things consistent and easier to manage. If we choose to have
multiple
versions represented in the various projects in trunk then we might need
to
do a little more pom cleanup to ensure that we can support this
Looking at the next stage of the release process, it is either to
rollback or to promote. It doesn't look like there is anything that
needs doing in SVN if we promote the staged artifacts which makes me
think they should right now be at 0.2-incubating-SNAPSHOT. However, if
we need to go down the rollback route for some reason then the
instructions [1] for rollback suggest what's in SVN should stay as it
is. Anyone wish to comment?
[1]
http://maven.apache.org/plugins/maven-release-plugin/examples/rollback-release.html
What was being proposed was just 2 things and I don't think either of them
will impact a potential rollback.
1) Changing the entries that still have 0.1-incubating-SNAPSHOT to
0.2-incubating-SNAPSHOT. This should only be for projects that are not
currently up for vote anyway and so it should not be affected by a rollback.
Of course, if we did rollback we would once again have an inconsistency
between 0.1-incubating-SNAPSHOT components and 0.2-incubating-SNAPSHOT - but
that should be just a temporary issue while a new RC is being created which
is usually much quicker on the second time around.
2) Changing the entries that currently have 0.1-incubating to
0.2-incubating-SNAPSHOT. I think all of these entries were manually edited
to reflect to the proposed release. Therefore, the maven-release-plugin
rollback would also not affect these entries.
In fact mvn versions:update-parent changed the<parent><version>
element. The procedure was to run this before running mvn
versions:use-releases. That said, I think these commands are just a
convenience over doing it manually.
I agree.
Of course, if we did rollback we would have inconsistent versions again -
particularly for those versions that were manually updated in #2 - but that
would also be the case even if we don't update them now -
0.1-incubating-SNAPSHOT (after a rollback) doesn't match
0.2-incubating-SNAPSHOT (if we do update now) or 0.1-incubating (if we don't
update now).
I'm +1 for moving up to 0.2-incubating-SNAPSHOT then figuring out what
we need to do later if we need to cut another RC.
I'm not quite sure what changes are being proposed here. I would definitely
leave all references to the parent and eba-maven-plugin at 0.1-incubating until
there is some need to change them. Depending on snapshot versions should be
avoided when possible. I would look carefully at upgrading other snapshots to
make sure there is a dependency on code changes since the release. Slightly
annoying, but I think we already decided that we weren't going to keep the
subprojects in lockstep..... this is where it starts to show.
thanks
david jencks
Joe
--
Joe
