[
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 20:23, David M Williams wrote:
> I guess off-topic, but why would someone choose aop vs. no_aop? I am sure
> part of the answer is "if you need to ask, you don't need to know" :) but,
> I'm wondering if it is likely there will ever be a "aop=true" version in
> Orbit?
One use case for no-aop version of guice are platforms that don't support bytecode generation like android devices.
>> From Guice Site:
Guice 2.0 makes AOP optional. If your platform doesn't support bytecode generation, you can download a version of Guice that doesn't include AOP support. This is most useful for mobile platforms like Android. This version also lacks fast reflection and line numbers in error messages. For this reason, we recommend Guice+AOP 2.0 even in applications that don't use method interceptors.
> Also off topic: was the CQ specific to the no_aop version? Sounds like
> "source the same, but bytes codes different" is a new area of "IP
> Clearance" that hopefully doesn't get complicated, nor common place.
Ähm... At least it's the same source and few calls are replaced by reflective counterparts. Is there a need to get back to IP team? If so, I guess Xtext would be fine with AOP variant too since 2.0 was using AOP alliance.
Check: Yes/No?
>> As long as P2 takes care that aopalliance packages are installed when
> needed, I'm fine.
>
> I believe the rule is that if the "import package" does not give any
> matching attribute, both p2 and OSGi interpret that as "don't care" and
> would feel free to choose either (blank, aop=true, or aop-false), but if
> you specify aop=false on your import package, then p2 and OSGi must find a
> package that specifies aop=false. Test early, test often :) It would
> actually be nice to have an "aop=true" version to test with .... maybe you
> could play with a locally built one, exported as deployable plugin from
> your IIDE with those values (once with nothing, and again with aop=true,
> perhaps changing description to match (I am not talking about "real code"
> here), add that as a "test repo" along with the eventual orbit repo and
> make sure some "test installs" pick up the versions as expected. If it
> does all work as expected, you might open a bug or pass along the info to
> the Google Guice folks? Part of the side purpose Orbit is (sort of) to
> encourage the world to make OSGi bundles and make them better :) ... maybe
> this could turn into a good success story? :)
Well, yes. Say: It depends on your answer to above yes/no question ;)
Thanks,
Marcel
>
> Thanks,
>
>
>
>
> From: Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>
> To: Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>,
> Date: 03/06/2012 01:51 PM
> Subject: Re: [orbit-dev] Updating to Guice 3.0.0.no_aop
> Sent by: orbit-dev-bounces@xxxxxxxxxxx
>
>
>
>
> 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
>
>
> _______________________________________________
> 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
