Re: [orbit-dev] Updating to Guice 3.0.0.no_aop

[Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>]

On 06.03.2012, at 19:03, David M Williams wrote:

>> Waiting little longer for potential OSGI experts' comments then.
> 
> Ok, now after thinking about this, having "no_aop" in the qualifier is
> wrong and unworkable ... speaking as an OSGi expert :)

:-)

> The key is that the "matching attributes" such as "vendor" in the
> Export-Package directive are relatively arbitrary, so you could use
> something like
> 
> Export-Package: com.google.inject; aop=false; version="1.3", ....

Sounds good to me. Guice comes with a large set of extension fragments. But as far as I know, none of them is actually distinguishing whether the base framework is +/- aop. So I think it would work.


> You'd also want to document clearly in the the Bundle-Description: that
> this was the "no-aop" version.

OK.

> If someone wanted to use "require-bundle" then I think they'd have to
> simply "require" the exact version/qualifier that had the aop or no_aop
> they desired (that is, not sure there is a similar concept for "require
> bundle".

If no one complains... OK for me. As long as P2 takes care that aopalliance packages are installed when needed, I'm fine.

> So, I think that's the right approach. If anyone has other insights, that'd
> be great.
> 
> Second issue: You (and they) say have both 1.5 and 1.6 as minimum EE
> environments, but I do not think that is ever needed. A minimum of 1.5
> includes 1.6 so specifying both is redundant (unless, I a missing
> something?) It does not rule out 1.7, for example.


I didn't touch it because I wanted to make only minimal changes.
I'll remove 1.6.


I'll trigger the build later after the current run finished.


> From:	Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>
> To:	Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>,
> Date:	03/06/2012 09:54 AM
> Subject:	Re: [orbit-dev] Updating to Guice 3.0.0.no_aop
> Sent by:	orbit-dev-bounces@xxxxxxxxxxx
> 
> 
> 
> 
> 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
> 
> _______________________________________________
> 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