[
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:59, David M Williams wrote:
>> 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?
>
> I doubt the IP Team would feel a need to "revisit" clearance, but would be
> good to add a comment to the Orbit CQ that "the binary version put into
> Orbit was then no_aop version provided from Google (no difference in
> source, just specifying the exact binary version chosen for Orbit) ... I
> think future "piggy back" users who might want to know ... then IP team
> could ask if they wanted to know more (sorry, don't mean to add to your
> work load ... honest).
ATO contains that record now.
> New topic, for what its worth, I've been trying to read spec or find
> example for the "require bundle" case ... and found, in spec,
> <quote>
> The Bundle-SymbolicName header can specify further arbitrary attributes
> that must be matched
> before a bundle is eligible.
> </quote>
>
> So, maybe the exact same principle can be applied to the bundle's symbolic
> name and any corresponding "require-bundle" users ... but, I've not found
> any examples of that, so it would (also) take some testing.
Interesting. Never heard of this before. I wonder how to specify the two bundles in the same repository then...
Anyways, I can imagine to spent some time on this after M6 (I hope this won't get lost). If someone actually needs that particular no-aop or aop version I'll have a closer look (after M6) how to solve that.
Thanks,
Marcel
>
> I hope this is helpful,
>
>
>
>
>
> From: Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>
> To: Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>,
> Date: 03/06/2012 02:34 PM
> Subject: Re: [orbit-dev] Updating to Guice 3.0.0.no_aop
> Sent by: orbit-dev-bounces@xxxxxxxxxxx
>
>
>
> 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
>
> _______________________________________________
> 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
