Open GoogleCodeExporter opened 9 years ago
Ideally Annotations and UniqueAnnotations could be moved to the util package,
while I
guess Errors and ErrorsException could either be moved to a new errors package,
the
top-level package, or the util package too.
Once these classes are in non-internal packages the extensions should resolve
OK.
Original comment by mccu...@gmail.com
on 20 Jan 2009 at 5:04
@mcculls is it possible to expose the classes in internal to extensions? I'd
prefer we not release these APIs
externally yet. Does OSGi have a 'friend' concept?
Also, is there a tool that can validate my OSGi bundles to test for problems
like this one?
Original comment by limpbizkit
on 26 Jan 2009 at 1:28
If you want to keep these classes internal but expose them to extensions, then
the
best solution is to mark the extensions as fragments that attach to the main
Guice
bundle. Fragment bundles use the same classloader as their host and will
therefore
see internal packages.
(there are other "friend" style mechanisms in Equinox, but these are
non-standard)
I've attached a patch that adds the necessary fragment headers and cleans up
some
import statements as well. FYI: you may see a few Bnd warnings about
non-matching
referrals, but these can be safely ignored.
Regarding a tool to validate OSGi bundles, you can use Bnd to verify the
content:
java -jar lib/build/bnd-0.0.305.jar print -verify build/dist/*-snapshot.jar
which will report the missing internal import for the extensions and other extra
bundles. Note these problems will still be reported even when the extensions are
marked fragments, but it won't now cause a problem in practice.
Also the main Guice bundle will always report a couple of missing imports:
com.google.common.base
com.google.inject.internal.asm.util
both due to some indirect/string references that are never used at runtime.
For a better test of the actual bundles you could use one of the OSGi
frameworks and
check the bundles all install and resolve. OSGi integration testing is
unfortunately
still ad-hoc these days (tooling is being developed as I type ;)
I don't have much time this month (or next!) but I could provide some tests
later on
this year if you're interested. Until then feel free to look at the following
links:
http://wiki.ops4j.org/display/ops4j/Pax+Runner
http://felix.apache.org/site/apache-felix-file-install.html
You can use Pax-Runner to download and setup an OSGi framework (say the
reference
implementation, Equinox) and deploy the FileInstall bundle. This monitors a
folder
and installs any JARs you add, and uninstalls any that are removed.
(shameless plug: the OSGi in Action book might also help
http://manning.com/hall/)
Original comment by mccu...@gmail.com
on 27 Jan 2009 at 6:28
Attachments:
I'd like to get this patch into Guice 2.1 if possible.
Original comment by mccu...@gmail.com
on 30 Mar 2009 at 10:59
Original comment by limpbizkit
on 26 Apr 2009 at 9:36
This patch didn't make it into 2.0, so rescheduling it for 2.1
Original comment by mccu...@gmail.com
on 21 May 2009 at 9:02
Will make sure this patch is up-to-date as part of my general OSGi cleanup for
2.1
Original comment by mccu...@gmail.com
on 31 Oct 2009 at 4:02
Folded this into http://code.google.com/p/google-guice/issues/detail?id=439
Original comment by mccu...@gmail.com
on 4 May 2010 at 10:17
Original issue reported on code.google.com by
Rinsvind@gmail.com
on 15 Jan 2009 at 5:15