For the specs, there are generally 2 version identifiers. The first
level is the implementation level the spec is supposed to be at. For
example, javamail 1.4 or javamail 1.3.1. The second is the Geronimo
release version of that specification. For example, the javamail 1.4
spec in trunk is currently at the 1.2-SNAPSHOT level. Does the
OSGIfication of these specs need to capture both levels?
Also, for the javamail spec, there's a separate subtree for the Provider
implementation, which also includes an uber jar that bundles the
provider and spec classes in one jar file. I suspect these should also
have OSGI bundles too. The SVN tree for these packages can be found here:
https://svn.apache.org/repos/asf/geronimo/javamail
Rick
Guillaume Nodet wrote:
So I've just commited a patch for everybody to review.
I have tested some of the bundles inside servicemix 4.0, so at least
i'm confident it won't break servicemix ;-)
Seriously, they seem to be ok, though i had to limit the exported
package from stax-api to javax.xml.stream* to not clash with other
packages from the system bundle (I suppose this is the reason).
See http://svn.apache.org/repos/asf/geronimo/specs/trunk/
On 9/21/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
For ServiceMix 4.0, which will be based on OSGi, I will need to have
OSGified versions of some of the spec jars that geronimo provides.
It's quite easy to do in ServiceMix (see
http://svn.apache.org/repos/asf/incubator/servicemix/branches/servicemix-4.0/bundles/
for servlet, j2ee-management, jms mainly), but I think it would be
more useful for other projects if the specs jars were bundles
themselves.
This is quite a simple process that can be done incrementally without
any real side effect and low risk of regression. So unless someone
objects, I'd like to start working on that.
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
