Skip to main content

[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

On 06.03.2012, at 15:36, David M Williams wrote:

> 
>> 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.

It's _version_. The original manifest looks like this

Bundle-Name: guice
Bundle-RequiredExecutionEnvironment: J2SE-1.5,JavaSE-1.6
Bundle-Copyright: Copyright (C) 2006 Google Inc.
Bundle-Vendor: Google, Inc.
Bundle-Version: 3.0.0.no_aop
Bundle-SymbolicName: com.google.inject
[...]

> 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?).

Using vendor is suggested by http://wiki.eclipse.org/Bundle_Naming#Issue_3_:_Distinguishing_different_implementations
vendor doesn't feel appropriate, I agree.


> 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".

From http://code.google.com/p/google-guice/wiki/OptionalAOP:

= Building Guice without AOP = 
Guice has an ant task that creates a modified copy of the Guice source-tree. The copy uses the *munge* preprocessor to remove all bytecode-dependent APIs. Use the following commands to build Guice without AOP support:
[...]

So it's basically the same source but a different bytecode.

> 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?

Waiting little longer for potential OSGI experts' comments then.
Thanks for your thoughts on this.

Marcel


> 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
> 
> 
> 
> _______________________________________________
> orbit-dev mailing list
> orbit-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/orbit-dev

Thanks,
Marcel

-- 
Eclipse Code Recommenders:
 w www.eclipse.org/recommenders
 tw www.twitter.com/marcelbruch
 g+ www.gplus.to/marcelbruch



Back to the top