frjaeger220 / google-guice

Automatically exported from code.google.com/p/google-guice
Apache License 2.0
0 stars 0 forks source link

Verify OSGi headers for 2.1 #439

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
This is a placeholder task to remind me to check the OSGi headers before
2.1 is cut (scheduled for late 2009?). For example, we have a new
dependency to the javax.inject library.

Original issue reported on code.google.com by mccu...@gmail.com on 15 Oct 2009 at 7:02

GoogleCodeExporter commented 9 years ago
Potential patch which simplifies the OSGi metadata given that extensions will 
now be
fragments to the main bundle so they can use the Guice internals. This 
incorporates a
fix for issue 311, but doesn't include the AOP patch in issue 337.

Original comment by mccu...@gmail.com on 16 Oct 2009 at 3:09

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by mccu...@gmail.com on 31 Oct 2009 at 4:01

GoogleCodeExporter commented 9 years ago
Once the dust has settled from issues 343, 443, etc. I'll update this patch.

Original comment by mccu...@gmail.com on 2 Nov 2009 at 8:15

GoogleCodeExporter commented 9 years ago
Description
===========

The attached patch (GUICE_ISSUE_439_20100504.patch) tidies up the OSGi headers 
in the
main Guice JAR and the various extensions. Extensions that use internal Guice 
methods
are tagged as fragments, which means they'll be automatically attached to the 
Guice
JAR when installed on an OSGi framework (so they can see the internals). And 
because
they'll be attached, we ignore all "com.google.inject.*" generated imports for
fragments (see the Import-Package line in common.xml).

The api.version is set back to 1.3 - note that this is the compatibility 
version of
the API, not the version of the release. The last release used an api.version 
of 1.2
and as the code is still (majorly) compatible with 2.0 we should use an 
api.version
of 1.3 for the next release to indicate that there have been additions, but no 
major
breakages for clients.

We're also using the latest stable version of BND (0.0.384 - binary also 
attached).

The Bundle-Version macro has changed slightly - if the version tag doesn't 
start with
a number (ie. "snapshot") then we use the simpler "0.0.0.snapshot" convention 
rather
than prefixing the api.version. This is to avoid further confusion between the
release version and api.version.

We no longer use a DynamicImport-Package for aopalliance, because it's now 
required.
We also turn off calculation of "uses" constraints (-nouses) to keep the 
manifest
simple and concise.

NOTE: I tested the bundles on an OSGi framework (Apache Felix) with the 
necessary
support bundles (javax.inject, aopalliance, etc.) and they all resolve as 
expected.

Original comment by mccu...@gmail.com on 4 May 2010 at 10:16

Attachments:

GoogleCodeExporter commented 9 years ago
PS. the following SVN directories appear to be empty and can be pruned:

  src/com/google/common
  src/com/google/common/collect
  src/com/google/common/base
  src/com/google/inject/tools/jmx
  src/com/google/inject/jndi
  test/com/google/inject/tools
  test/com/google/inject/tools/jmx
  test/com/google/inject/commands

Original comment by mccu...@gmail.com on 4 May 2010 at 10:25

GoogleCodeExporter commented 9 years ago

Original comment by mccu...@gmail.com on 4 May 2010 at 11:27

GoogleCodeExporter commented 9 years ago
fixed in r1158.  thanks very much for the patch, Stuart!

Original comment by sberlin on 9 May 2010 at 12:52