BTW, the "quick" way to get the build working is to simply update the
application dependency management to depend upon consistent versions of
the various bundles - but that's not really a good fix as it breaks the
notion of independent projects - so I suspect the real fix would have to
be in the way that we specify the import package statements in various
bundles - but that is a much more difficult fix.
Joe
On 4/13/10 9:46 AM, Joe Bohn wrote:
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
