[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [orbit-dev] Updating to Guice 3.0.0.no_aop
|
> 2. I renamed the Bundle-Version to 3.0.0.no_aop_qualifier to show
> that this bundle is the no-aop variant of Guice. The name "3.0.
> 0.no_aop" is used by the Guice team itself. Here, however, I wonder
> whether a vendor attribute should be used if someone wants to use
> the standard Guice with AOP. If no-one stands up, I'll stick to the
> Guice-given defaults.
I do not object to using 'no_app' in the qualifier ... but, it does seem a
bit odd. Keep in mind, I've only briefly thought about this, and am not
familiar with "Guice".
> The name "3.0.0.no_aop" is used by the Guice team itself.
Are you saying they use that in the _version_ of Guice? Or the _name_? In
particular, do they produce an OSGi bundle and use that as the version? If
so, then I think that would mean "3.0.0.no_app_qualifier" would be ok.
I've have to check all the OSGi manifest directives/properties, but sounds
like something like "vendor" is a little more appropriate (are there other
candidate "properties" that would be useful, or is "vendor" the only
choice?).
What does "no AOP" mean, exactly? Does it happen to mean "whole packages"
are missing, without *.aop.* packages? If so, I'm surprised anything is
needed at all, and perhaps another bundle/fragment with "aop" in name (id)
would be more appropriate when aop is provided. I'm concerned about putting
part of the bundle's functional semantics in the _version_ "number".
So, I am not saying I know the right answer and feel free to do it how you
think best ... that is, I am not objecting to you doing it ... but ...
thought I'd "stand up" to say I think you are right to ask for feedback. If
no OSGi experts speak up on this list, perhaps you could also ask on
OSGi-dev list for advice?
Thanks,
From: Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>
To: Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>,
Date: 03/06/2012 07:42 AM
Subject: [orbit-dev] Updating to Guice 3.0.0.no_aop
Sent by: orbit-dev-bounces@xxxxxxxxxxx
Hi,
I'm going to update Guice to 3.0.0 tonight (after the build is fixed). I've
made a few changes to the original manifest which I'd like to present
before committing this to Orbit:
1. I've added com.google.inject.internal;version="1.3";x-internal:=true,
since this package is used by XText.
2. I renamed the Bundle-Version to 3.0.0.no_aop_qualifier to show that this
bundle is the no-aop variant of Guice. The name "3.0.0.no_aop" is used by
the Guice team itself. Here, however, I wonder whether a vendor attribute
should be used if someone wants to use the standard Guice with AOP. If
no-one stands up, I'll stick to the Guice-given defaults.
3. I've added Eclipse-ExtensibleAPI: true to enable PDE to recognize and
handle extension fragments properly. This was added 23.12.2011 to
Guice.jar.
See
http://code.google.com/p/google-guice/source/detail?r=abfe40d6bf6e3b1a3703869c85dae9a0315cb782
The final manifest is given below. If there are any issues with it
(especially with Xtext needs), let me know.
Best,
Marcel
Manifest-Version: 1.0
Export-Package: com.google.inject;version="1.3",
com.google.inject.binder;version="1.3",
com.google.inject.internal;version="1.3";x-internal:=true,
com.google.inject.matcher;version="1.3",
com.google.inject.name;version="1.3",
com.google.inject.spi;version="1.3",
com.google.inject.util;version="1.3"
Bundle-Name: Google Guice (no_aop)
Bundle-RequiredExecutionEnvironment: J2SE-1.5,
JavaSE-1.6
Bundle-Copyright: Copyright (C) 2006 Google Inc.
Bundle-Vendor: Eclipse Orbit
Bundle-Version: 3.0.0.no_aop_qualifier
Bundle-ManifestVersion: 2
Bundle-Description: Guice is a lightweight dependency injection framew
ork for Java 5 and above
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
Bundle-DocURL: http://code.google.com/p/google-guice/
Import-Package: javax.inject
Bundle-SymbolicName: com.google.inject
Eclipse-ExtensibleAPI: true
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev
