[
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
|
> 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 reason is pretty obvious, now that I think about it. The whole reason
for the versions and qualifiers is so that consumers can specify a range
they could live with, such as
Require-Bundle: com.google.inject;bundle-version="[3.0.0,4.0.0)",...
Hence, the version/qualifier could never be gaurenteed to increase
monotonically, if there was both a "no_aop" version, and an "aop" version.
How could people be assured they'd "get" the one they wanted? For example,
a future "aop" version might be versioned as 3.0.0.v2012 (which would be
"higher" than the one versioned as "3.0.0.no_aop.." (due to the initial 'v'
being greater than the initial 'n'.
I do know how to make this with work Export Package (and those that consume
using import package). Bug 258439 gives a similar example, where bundles
with same IDs have packages with different contents.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=258439
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", ....
Then, if it mattered to those consuming it, they could specify the matching
attribute on their "import package" statement.
You'd also want to document clearly in the the Bundle-Description: that
this was the "no-aop" version.
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".
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.
Thanks,
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
