Cool.
Just FYI, when this topic was originally raised it was in the context of
the APPLICATION.MF where we were attempting to substitute the version in
a hard-coded APPLICATION.MF when generating the EBA. Since that time
the eba-maven-plugin was introduced which will automatically generate
the complete APPLICATION.MF. This is what we are now using in the samples.
Joe
Guillaume Nodet wrote:
FWIW, I've added to the latest maven bundle plugin a goal that can be used
to transform a string into a correct osgi version.
The goal is now run automatically in the aries build and you can use the
aries.osgi.version.clean property to obtain the correct syntax corresponding
to the maven version.
On Wed, Mar 3, 2010 at 18:48, Joe Bohn <[email protected]> wrote:
Sorry, I thought I replied to this yesterday but see that I didn't.
Jeremy Hughes wrote:
On 2 March 2010 19:30, Joe Bohn <[email protected]> wrote:
Thanks David.
After I sent my last note I recalled another place in AriesTrader with
hard-coded versions. The APPLICATION.MF files used for the two EBAs
that
are generated includes the bundle version - which is a little different
than
the maven version. Where the maven version is currently
1.0.0-incubating-SNAPSHOT the bundle version generated using the
maven-bundle-plugin is 1.0.0.incubating-SNAPSHOT to conform to the OSGi
version scheme.
Are you saying we couldn't quite generate the APPLICATION.MF using
resource filtering because the ${version} will be
1.0.0-incubating-SNAPSHOT instead of 1.0.0.incubating-SNAPSHOT?
Not necessarily. It's just that we'll need to keep the different format in
mind.
There are two things which might make this a moot point:
1) If the eba-maven-plugin is enhanced to generate the APPLICATION.MF
then
we can use that to resolve the issue.
Yes I agree eba-maven-plugin should pull the same trick as the
maven-bundle-plugin to ensure version numbers fit with the OSGi spec
(whatever the logic for that conversion is).
Yes.
2) Even though this is an issue with SNAPSHOTs I imagine it isn't an
issue
with a non-snapshot release because it won't container the "-XXX"
qualification.
I think it'll continue to be an issue while we are using the -incubating
suffix.
Agreed. I wasn't sure if we were releasing 0.1 or 0.1-incubating.
Optionally, I could also just omit the APPLICATION.MF altogether from the
AriesTrader EBAs since I understand that it is not required. That might
be
quickest fix for now.
Do all the AriesTrader .eba files contain, by value, all the bundles
they need? And, is that set transitively closed? If so then you
certainly could remove the APPLICATION.MF. Or is it using the OBR
resolver integration code to pull in bundles from a repository?
At the moment the eba includes the complete set of bundles by value.
However, I'm not sure if that will always be the case (or even if it will be
the case in all environments for some of the dependencies, such as slf4j).
I'll experiment a bit.
Joe
David Jencks wrote:
On Mar 2, 2010, at 10:33 AM, Joe Bohn wrote:
I agree that we should make a global change to 0.1-incubating-SNAPSHOT
first. Why wouldn't we just do that now?
I started doing some experiments here...
running
mvn versions:set -DnewVersion=0.1-incubating-SNAPSHOT
in root and parent upgrades everything maven knows about just fine.
However there's (1) mentioned below and also a hardcoded version in two
blueprint-itests.
According to
http://wiki.ops4j.org/display/paxexam/Configuration+using+Maven+Plugin
we should be able to replace the hardcoded versions with
.versionAsInProject()
if we run the maven-paxexam-plugin on the project. However I can't get
it
to work yet.
Just a heads-up on some other issues related to versions in samples.
There are two potential problems that I am aware of:
1) For both Blog-Sample and AriesTrader there are hard-coded version
references in the Equinox assembly config.ini file which are used to
specify
the bundle jars that are to be started for the assembly. Naturally, the
versions of the aries bundles in this file won't be updated by the
maven-release-plugin. I'm not sure of a good solution for this beyond
just
manually changing the config.ini files prior to creating a release
candidate.
I think we might be able to work around this by putting the config.ini
files in src/main/resources/filtered-resources and defining a bunch of
properties in an appropriate pom and using them for the version imports
of
the aries subproject dependencyManagement imports in the samples root
pom.
I haven't tried this yet...
2) I think there is still an unresolved issue related to Blog-Sample
and
how we might be able to demonstrate a bundle upgrade scenario. I'm
not
sure if this capability is included yet in Blog-Sample - so it might
still
be a non-issue at the moment. However, we had some discussion on this
a
week ago or so related to how we might be able to include multiple
versions
of components in the sample so that an upgrade scenario could be
demonstrated. If that is still a goal for the 0.1 release we will need
to
come up with some solution.
no ideas from me on this one :-)
thanks
david jencks
Joe
David Jencks wrote:
I think everything is ok.... I think (at least with dryRun=true) that
the release plugin builds the project first as-is and checks that
signing
etc works.
I added autoVersionSubmodules=true in the root parent pom which will
make things work more smoothly :-)
I really recommend changing the version to 0.1-incubating-SNAPSHOT
first, I'm happy to do this if you want.
thanks
david jencks
On Mar 2, 2010, at 9:14 AM, Jeremy Hughes wrote:
scratch that. I'm working thru this:
http://maven.apache.org/developers/release/apache-release.html as
there's several steps I haven't done.
On 2 March 2010 16:17, Jeremy Hughes <[email protected]> wrote:
On 2 March 2010 02:28, David Jencks <[email protected]> wrote:
I've done most of what I think is needed for aries to be basically
releasable. There are some bits left and possibly stuff I've
missed.
1. legal file review. There are a bunch of NOTICE files that claim
that
work from osgi is included. Really? license and notice files are
supposed
to apply to what is actually in an artifact or checkout. Are some
of
our
source files copied from an osgi source? Also all the legal files
that end
up in binary artifacts need to be checked. Also we need to run the
rat
plugin: this should be configured in the default pom. Not sure if
I
will
get to this.
2. actually using the eba-maven-plugn. I'm not entirely sure how
to
make
sure that an eba is working so I didn't mess with this. I think
the
plugin
itself is working well enough to use though.
2. ordering dependencies and dependency management. I find it
convenient to
have these alphabetized so I can find what I'm looking for, but I
haven't
done this in most poms. I'm not sure why there isn't a usable tool
for
doing this but I haven't found one. Dull but useful...
3. It would probably be a really good idea to run mvn
dependency:analyze and
look carefully at the results. The results from this can require
interpretation so its best if someone who is very familiar with how
the code
works does this.
4. before a release all snapshots need to be resolved to released
versions.
I don't know if there are any snapshots.
To summarize what I've tried to do:
1. default-parent has dependency management for the basic osgi
dependencies
that all projects are pretty sure to use including the pax stuff
used
mostly
for testing.
2. each subproject has legal files in its checkout root
3. each subproject has an scm element in its pom, but no others do.
4. each subproject has dependency management for everything
included
in it.
In addition, it has its subprojects listed in dependency
management.
(this
is bent slightly for the samples). This means that
(a) modules in a subproject don't need to include versions for use
of
other
modules
(b) you can get dependency management for all the modules in a
subproject
by depending on the subproject pom with scope import. (see the
samples pom
for an example).
5. As a result of (4), modules don't have any versions in any
dependency
elements.
Release is going to involve...
releasing the parent
In trunk/parent I tried:
mvn -DdryRun=true release:prepare -Papache-release
Providing 0.1-incubating for the release version
Defaulting to parent-0.1-incubating for the SCM release tag
Defaulting to 0.2-incubating-SNAPSHOT for the new development
version
then when it builds the 'Top Parent POM' it outputs this:
[INFO] [INFO]
------------------------------------------------------------------------
[INFO] [INFO] Building Aries :: Top Parent POM
[INFO] [INFO] task-segment: [clean, verify]
[INFO] [INFO]
------------------------------------------------------------------------
[INFO] [INFO] [clean:clean]
[INFO] [INFO] Setting property: classpath.resource.loader.class =>
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] [INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] [INFO] Setting property: resource.loader => 'classpath'.
[INFO] [INFO] Setting property: resource.manager.logwhenfound =>
'false'.
[INFO] [INFO] [remote-resources:process {execution: default}]
[INFO] [INFO] [site:attach-descriptor]
[INFO] [INFO] [assembly:single {execution: source-release-assembly}]
[INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
skipping
[INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
added,
skipping
[INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added,
skipping
[INFO] [INFO] Building zip:
C:\cygwin\home\hughesj\oss\aries\trunk\parent\target\parent-1.0.0-incubating-SNAPSHOT-source-release.zip
[INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
skipping
[INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
added,
skipping
[INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added,
skipping
[INFO] [INFO] Preparing source:jar
[INFO] [WARNING] Removing: jar from forked lifecycle, to prevent
recursive invocation.
[INFO] [INFO] No goals needed for project - skipping
[INFO] [INFO] [source:jar {execution: attach-sources}]
[INFO] [INFO] [javadoc:jar {execution: attach-javadocs}]
[INFO] [INFO] Not executing Javadoc as the project is not a Java
classpath-capable package
[INFO] [INFO] [gpg:sign {execution: default}]
so it seems to be outputting 1.0.0 artifacts still. Any ideas?
Then stops at the gpg stage. I thought it would prompt me for my key
passphrase at this point. Do I need gpg-agent to be running?
updating the parent version wherever it is used (all subproject
parents)
releasing the subprojects in an appropriate order and updating
their
versions wherever they are used.
It might be worthwhile changing the pom version to
0.1-incubating-SNAPSHOT
(or something similar, 0.0-incubating-SNAPSHOT?) before doing this
because
then the versions plugin can be used to update use of a subproject
to
the
newly released version of what it uses. Going from
1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this.
As noted in the "root" pom, don't try to release the root pom and
don't try
release everything at once from the root pom.
thanks
david jencks
On Feb 24, 2010, at 11:55 PM, David Jencks wrote:
I started looking into cleaning up the build, and of course it is
taking
longer than I expected.
I'm seriously hampered by failing tests in a fresh checkout.
There are some projects in application that stop compiling if you
alphabetize the dependencies. It looks like osgi 3 artifacts are
getting on
the maven classpath before osgi 4.2 artifacts. Adding exclusions
to
the
dependencies seems to fix it if you can figure out where the out
of
date
jars are coming from.
The build is already much closer to a multi-release model than a
single
release model.
I've diffed what I have so far and attached it to ARIES-173. It
includes
scm info and a lot of version corrections. Due to the failing
tests
I'm not
too comfortable committing it.
Is anyone else seeing test failures locally?
thanks
david jencks
On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
Hi David,
It 'd be great if you are willing to fix these build issues,
since
you
just went through a big release in Geronimo. :)
I know the maven release plugin isn't friendly to use some cases,
so
it is best we get these resolved to make our release process a
bit
easier.
EBA plugin would be a very nice add-on, if it comes in time with
the
release.
Thanks
Lin
On Tue, Feb 23, 2010 at 8:56 PM, David Jencks
<[email protected]>
wrote:
I would like to understand the problems you see better, but I do
not
have
the maven background you guys have, any chance you could
explain
what
the
problems are, why they are problems and the solution at some
point?
The biggest immediate problem is that without correct svn info
you
can't
do
a release with the release plugin. I'm pretty sure the way its
set up
now,
when you try, the tag will be under maven's apache pom, not
aries.
(you'll
fail unless you happen to be a maven committer too). You
definitely
don't
want to try to do a release without the release plugin.
Organizationally there's no way that for instance blueprint,
application,
and samples should always be released in synchrony. Any time
two
of
them
happen to be ready for release at the same time it will be
purely
accidental. Right now everyone wants to get a milestone out the
door,
but
looking at the different projects their state of completion is
pretty
much
wildly different. A decision to release all of them at once is
not
based in
any way on them being equally complete. I'm suggesting that
since
build
fixes are needed anyway, why not set up a maintainable structure
that
will
continue to work beyond this publicity release. The benefit to
users is
that aries will be able to release bits in a timely fashion;
otherwise
the
entire project will never be in a releasable state at once. (I'm
only
exaggerating a little bit :-)
What got me looking at this at all is what look like wild
gyrations that
don't really use maven properly to get an .eba (or some
artifact)
out
the
door. This might be ok for one release but (a) I think this can
be done
directly with the assembly plugin short term and (b) an
eba-maven-plugin
seems like the obvious more long term solution.
I'm willing to fix the build and probably work on an eba plugin,
but
want to
be sure this is ok with everyone first.
thanks
david jencks
Thanks
Alasdair
On 23 Feb 2010, at 18:18, David Jencks <[email protected]
wrote:
This discussion got me worried enough to take a look at the
aries
build.
Now I'm even more worried.
While it might feel good to try to push out a release as fast
as
possible
I'd prefer to see a sustainable build system in place first.
So
far
it
looks to me as if aries is going to be a bunch of loosely
coupled
subprojects. Building them all at once is not going to work
for
long.
I
think we should recognize that and put that in the build
system
now.
To me
this means:
1. a parent pom that isn't at the root of the svn trunk.
2. each subproject has pom info sufficient so it can be
released
(mostly
svn info) (right now this is completely missing everywhere as
far as
I can
see, which will result in ares getting tagged into svn as part
of the
apache
pom)
We can still have a "fake" pom that builds everything, but it
won't be
part of any release procedure.
Having separately released subprojects does not prevent having
a
single
vote on all the releases.
I'd suggest a few other pom tweaks such as using resources and
filtered-resources to distinguish when filtering is called
for.
In addition relevant to this particular bit of the thread, we
need an
eba-maven-plugin to assemble ebas. Getting this into a first
release
would
be a great idea IMO.
If there's general agreement I can spend some time playing
with
the
build
and possibly working on the eba plugin.
thoughts?
thanks
david jencks
On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
Jeremy Hughes wrote:
On 19 February 2010 13:09, Joe Bohn <[email protected]>
wrote:
I'd also like to see us release the sample applications but
I
think
there is
at least one complication. Both Blog Sample and
AriesTrader
generate
EBAs
using different techniques - but both leverage the
maven-antrun-plugin
to
finally produce a file of type "eba".
I realised the .eba file generated in the blog-assembly
module
wasn't
being pushed into my local repo. I've made some changes to
the
pom.xml
in ARIES-198 to fix this. So now it uses antrun to create
the
.eba
artifact and the build-helper-maven-plugin to push the
artifact to
the
local repo. I needed to add NOTICE and LICENSE files to the
.eba for
the ianal plugin in the verify phase to succeed.
I've not used the build-helper-maven-plugin before. Do you
know if
it
will work with the maven-release-plugin to push the eba
artifacts
when we do
a release? If so, then I should look at using the same
mechanism for
AriesTrader.
I think the result is that the eba will not be available in
a
maven
repository.
One of the differences is that AriesTrader first generates
a
jar
using
the
maven-assembly-plugin and then copies this to an eba. The
jar will
be
managed by maven and IIUC it should be deployable as an
"application"
even
with an extension of "jar" rather than "eba". If that is
correct
then
perhaps delivery of an application jar is an acceptable
approach
for
the 1st
release. Unfortunately I haven't actually setup my equinox
assembly
to
deploy the eba yet - it still deploys all of the individual
bundles.
Using the maven-assembly-plugin likely the preferred
approach
long
term. Perhaps we could copy the artifact to .eba and use the
build-helper-maven-plugin to remove the .jar artifact from
maven
control and add the .eba one?
I can give this a try for AriesTrader. If it doesn't work
out
- is
there anything wrong with the approach I mentioned earlier of
just
using the
jar artifacts rather than the eba artifacts? Will the
current
application
support only look at *.eba archives?
Joe
Guillaume Nodet wrote:
I'd like to see at least those included:
* blueprint
* jmx
* jndi
* transaction
I don't think applications are really usable yet and I
haven't
really
looked at JPA yet, so can't tell about it.
The transaction component is functional and we've been
using
it
mostly
unchanged since a long time in ServiceMix.
Do you have any particular concerns with it ? (I'm not
talking
about
declarative transactions for blueprint, note).
On Fri, Feb 19, 2010 at 04:19, Joe Bohn <
[email protected]>
wrote:
Thanks for the response (even while on vacation!) ... and
for
volunteering
to be the release manager. Your response helps me get a
better
picture
of
the plans.
I was really just interested in the general objectives
and
timing
since
it
hadn't been discussed yet. To get the release out in Feb
means
it
will
be
delivered next week. I'm afraid the hill might be a
little
too
steep to
climb that quickly but I'm happy to be proven wrong.
The more communication the better. It's important to get
everybody
thinking
and planning along the same lines (or understand quickly
if
there
are any
differences of opinion). Knowing that you are thinking
of
creating
a
release candidate next week means that we should be
getting
more
restrictive
on new content to avoid any unpleasant surprises.
I don't have any strong opinions on what should be in or
out -
but
in
general it doesn't make sense to release things that
aren't
functional.
At
the moment I'm not sure what those are - but I suspect
not
all of
the
components are fully functional yet (for example
transaction).
Best Regards,
Joe
Jeremy Hughes wrote:
Hi Joe, sorry I started setting myself up tuesday but am
now out
on
vacation until monday.
Personally, I think the 0.1 release should serve to get
what we
have
right now in the respectable form the ASF requires. So
'must
haves'
are to get the build in the right shape to create the
distribution
files that are acceptable to the IPMC. I think each main
area of
the
code deserves at least a README to describe what's
possible.
Since
this is the first release there are likely a few
unknowns
-
w.r.t
timing I hope/expect to get the release out this in feb.
If
there
are
particular JIRAs or other issues you feel should be
included
please
say. I'd like to rename the current JIRA version 1.0 to
0.1 and
target
issues for 0.1 appropriately and issues not for 0.1 to
target a
new
0.2 version. WDYT?
Cheers,
Jeremy
On 18 February 2010 15:39, Joe Bohn <[email protected]>
wrote:
Jeremy,
What are your current thoughts and goals regarding the
release
and
potential
target dates?
I think it would be good if you could summarize your
thoughts
in
an
email
or
perhaps on a page in the wiki that we can keep updated
as
we
make
progress.
Of particular interest would be the content that we
would
like
to
see
in
the first release (clarifying what we consider "must
have" from
"nice
to
have"), the current status of that content, target
dates
for
the
release,
and the process that we plan to use to generate the
release.
Thanks,
Joe
Jeremy Hughes wrote:
On 12 February 2010 09:39, Guillaume Nodet
<[email protected]>
wrote:
Great, thanks a lot. Let us know if you need any
help.
I guess if you take some notes, it would be
interesting
to
put
those
on the wiki.
Certainly will. It's been a while since I did one and
the
process
has
changed quite a bit :-)
On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
<[email protected]>
wrote:
Hi Kevan, thanks. I volunteer to be release manager.
Jeremy
On 11 February 2010 16:38, Kevan Miller
<[email protected]>
wrote:
Sounds like the consensus is for a release with all
components
at a
0.1
version number. Best to start with a simple
versioning
scheme,
IMO.
Personally, I don't view a 0.1 blueprint release as
an
issue.
Showing the ability to generate an Apache release
is
an
important
step
for the community. Would definitely like to see
this
happen...
We'll need a release manager. Any volunteers?
--kevan
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
Joe
--
Joe
--
Joe
--
Joe
--
Joe
--
Joe
--
Joe
--
Joe
