geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <>
Subject Re: geronimo 2.2 upgrades
Date Thu, 17 Nov 2011 22:40:05 GMT

On Nov 17, 2011, at 5:52 AM, Trygve Sanne Hardersen wrote:

> Thanks for the feedback Kevan!
> We understand from your comments that you are positive with regards to having the changes
integrated with Geronimo, but that they are too significant to be applied without further
discussion. We have no problem understanding this.
> Our goals with the project has been to 1. add some new features (i.e. spec changes),
2. upgrade to supported versions of 3rd party libraries (for instance CXF), 3. upgrade to
latest version of 3rd party libraries (SLF4J, Plexus and so on) and 4. better understand the
inner workings of Geronimo. We have not concerned ourselves with TCK compliance, though this
is obviously important from the community perspective.
> We have done the project on the 2.2 branch because 3.0 was too unstable (as in changed
too fast) for us to work with. Some of the changes are backports of your work on 3.0, others
should in our opinion be applied to 3.0 as well (ActiveMQ, CXF), and some are 2.2-specific
> For the community to better understand the implications of the changes, we suggest the
following approach:
> 1. We try to split the changes into smaller parts with specific areas of concern, and
create JIRA issues for each of them.
> 2. The community decides whether or not to accept the issues.
> 3. We commit and support the accepted issues.
> There will be quite a bit of work involved in splitting the patch, and some changes are
dependent on others. Before starting this we should come to agreement on which specs upgrades
are wanted. This will in most cases decide which major 3rd party frameworks should be upgraded.
We should also decide if the "latest and greatest" approach to minor 3rd party libraries (typically
commons-libraries) is feasible for Geronimo. There might not be a single answer to this.

Yes. I don't think you should start doing any work splitting things apart. Let's only start
that, when we feel it's necessary... Hopefully avoid any unnecessary work...

The biggest issue is likely to be -- can 2.2 pass the TCK with your changes? We'll probably
need to level-set our 2.2.1-SNAPSHOT testing -- get an accurate count of tests currently passing,
etc. Prior to incorporating any changes. There are some potential alternatives to consider
-- e.g. build Plugins that can replace server functionality, rather than integrate all function
into the server functionality. Much like the old OpenJPA plugin that added JPA 2.0 support,
replacing the old JPA function. 

> Trygve
> (we'll email the corporate CLA to

To simplify the software grant portions of the CLA, it will probably be easiest to attach
your two patch files to a Jira. Select the "donate to the ASF" button. Then reference these
files in the CLA.

It will also be useful, if you (and any other participants) submit an ICLA to secretary@.

Grants need to be cleared via the Apache Incubator. This is a process that we need to worry
about (not you).

Once we're cleared through the Incubator (it won't be long). We can start dividing up the
patches (if needed).


View raw message