Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] javax.transaction
I think Matthias is correct, that most of the gorp we'd leave as-is as we are just making available 3rd party content and if no reason to change it, then we do not.

One complication if see is the license statement ... and you'll have to check with IP staff on CQ ... is that it says

Bundle-License: https://glassfish.dev.java.net/nonav/public/CDDL+GPL.html
 
In my experience that usually means "the distributor can pick which license they want to use to redistribute ... and, since it's been deemed that EPL and GPL can not validly combined, then we (the Eclipse Foundation) always chooses CDDL, and we state that explicitly in the about.html file. I'm guessing that we'd want to change that "Bundle-License" directive then too, or just remove it. (Again, check with IP staff).

And if we modify it all ... and I we always do, since we'd still mark the provider as "Eclipse Orbit", it is signed with Eclipse cert, our build process will add things like Eclipse-SourceReferences :

then the correct form ... for the bundle version ... would be Bundle-Version: 1.2.0.b03_qualifier. The package exports would all stay the same.

And, when that is done, some care is needed to avoid having the qualifier increase each build. See
http://wiki.eclipse.org/Orbit/Adding_Bundles_to_Orbit#Avoid_qualifiers_that_change_with_date_and_time_of_each_build
 

> a released version should not use .qualifier

Who said that? :) That's not true for Eclipse. I think was just a personal editorial that some people like the Maven standard better than the Eclipse standard, but, we use the Eclipse standard:
http://wiki.eclipse.org/Version_Numbering

All that said, there is another option, and that is to treat it as a "pre-built" bundle, in which case we don't do anything to it ... except we do still sign it ... Doing this can be a little limiting, and a little tricky, and might take some updates to some build.properties files, so if interested in that approach, you should read: http://wiki.eclipse.org/Orbit/Adding_Bundles_to_Orbit#Adding_a_library_that_is_already_a_bundle

HTH





From:        Matthias Sohn <matthias.sohn@xxxxxxxxx>
To:        Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>,
Date:        05/29/2013 05:44 PM
Subject:        Re: [orbit-dev] javax.transaction
Sent by:        orbit-dev-bounces@xxxxxxxxxxx




On Wed, May 29, 2013 at 10:48 PM, Jesse McConnell <jesse.mcconnell@xxxxxxxxx> wrote:

I am starting to slog through the mess of CQ's we have for Jetty 9.1 to support the servlet 3.1 api, etc and I ran across a situation I wanted to bring up.

It seems that Oracle is working to make more of these sorts of dependencies osgi bundles so since I don't actually use osgi for...anything... what do you guys want to do here?  Should the default behavior be to tweak it to fall in line with eclipse practices for previous bundles?  Is osgi tolerant of these sorts of versioning things and it will just work?

I'll cut and paste the two different ones here: 

existing in orbit for 1.1.1:

Manifest-Version: 1.0

Bundle-Description: Provides open-source implementations of Sun specifications.

Bundle-Vendor: %Bundle-Vendor.0

Bundle-Localization: plugin

Fragment-Host: system.bundle

Bundle-RequiredExecutionEnvironment: J2SE-1.5

Bundle-Name: %Bundle-Name.0

Bundle-SymbolicName: javax.transaction

Bundle-Version: 1.1.1.qualifier

a released version should not use .qualifier

Implementation-Version: 1.1.1

Export-Package: javax.transaction.xa;version="1.1",javax.transaction;version="1.1"

Bundle-ManifestVersion: 2


------

And Oracles attempt for 1.2:

Manifest-Version: 1.0
Export-Package: javax.transaction;uses:="javax.enterprise.context,java
 x.enterprise.util,javax.transaction.xa,javax.interceptor";version="1.
 2.0.b03",javax.transaction.xa;version="1.2.0.b03"
Implementation-Version: 1.2-b03
Built-By: romano
Specification-Vendor: Oracle Corporation
Tool: Bnd-0.0.255
Bundle-Name: javax.transaction API
Created-By: 1.7.0_09 (Oracle Corporation)
Require-Bundle: system.bundle
Implementation-Vendor: GlassFish Community
Bundle-Vendor: GlassFish Community
Implementation-Vendor-Id: org.glassfish 
Bundle-Version: 1.2.0.b03

I think this is a legal OSGi conform version number, see e.g. [1]
 
Build-Jdk: 1.7.0_09
Bnd-LastModified: 1361865984022
Bundle-ManifestVersion: 2
Bundle-License: https://glassfish.dev.java.net/nonav/public/CDDL+GPL.h
 tml
Bundle-Description: Java(TM) JTA 1.2 API Design Specification
Specification-Version: 1.2
Import-Package: javax.enterprise.context,javax.enterprise.util,javax.i
 nterceptor,javax.transaction;version="1.2.0.b03",javax.transaction.xa
 ;version="1.2.0.b03"
Bundle-SymbolicName: javax.transaction-api
Bundle-DocURL: https://glassfish.java.net
Extension-Name: javax.transaction
Archiver-Version: Plexus Archiver


So, should I keep most of the superficial entries in there?  I think the b03 versioning and what not is a mess that I'll need to standardize to more traditional eclipse versioning, but since I don't deal with this stuff normally I thought I would ask for advice.

see [2] and [3] for OSGi manifest headers, Eclipse defines some more [4], I think the original spec for
manifests is [5] and Maven usually also adds a couple of additional headers [6].

[1] http://wiki.osgi.org/wiki/Bundle-Version
[2] http://wiki.osgi.org/wiki/Category:Manifest_Header
[3] http://www.osgi.org/Specifications/ReferenceHeaders
[4] http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fbundle_manifest.html
[5] http://www.cse.yorku.ca/tech/other/jdk1.2.1/docs/guide/jar/manifest.html
     http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#JAR_Manifest
[6] http://maven.apache.org/shared/maven-archiver/examples/manifest.html

--
Matthias _______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev

Back to the top