felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kriens <peter.kri...@aqute.biz>
Subject Re: Scala and osgi
Date Sat, 20 Nov 2010 11:44:25 GMT
Only RUNTIME annotations are imported because they're the only one that can cause imports ...

Kind regards,

	Peter Kriens

On 19 nov 2010, at 17:05, Guillaume Nodet wrote:

> Note that loading a class with annotations while annotations are not
> available never result in a NoClassDefFoundError, annotations are
> simply discarded, so I'm not sure that a mandatory package should be
> generated, maybe an optional one though.
> 
> On Fri, Nov 19, 2010 at 16:21, Justin Edelson <justin@justinedelson.com> wrote:
>> Peter-
>> This is perhaps a bit of lazymail, but will bnd by default create an Import-Package
statement for CLASS-retained annotations?
>> 
>> In other words, if you had
>> 
>> package foo;
>> 
>> import bar.MyAnnotation;
>> 
>> @MyAnnotation
>> public class MyClass {
>> 
>> }
>> 
>> Where bar.MyAnnotation has a RetentionPolicy of CLASS and is in a separate bundle,
what Import-Package header for the bundle containing package foo will be generated by default?
>> 
>> Thanks,
>> Justin
>> 
>> 
>> On Nov 19, 2010, at 8:58 AM, Peter Kriens wrote:
>> 
>>> There is a class in bnd that can do this: aQute.lib.osgi.Clazz, it does not need
access to the actual annotation classes.
>>> 
>>> bnd uses CLASS annotations for its DS support because it is a lot easier to parse
byte codes than source code.
>>> 
>>> Kind regards,
>>> 
>>>       Peter Kriens
>>> 
>>> 
>>> On 18 nov 2010, at 20:47, Felix Meschberger wrote:
>>> 
>>>> Hi,
>>>> 
>>>> Am Donnerstag, den 18.11.2010, 11:50 -0500 schrieb Justin Edelson:
>>>>> On Thu, Nov 18, 2010 at 3:35 AM, Felix Meschberger <fmeschbe@gmail.com>
wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> Am Sonntag, den 01.08.2010, 14:07 +0200 schrieb Reto Bachmann-Gmuer:
>>>>>>> Hi Atle
>>>>>>> 
>>>>>>> In the clerezza projects we're using more and more scala, the
biggest
>>>>>>> disandvantage for me is that the maven-scr-plugin doesn't work
for scala so
>>>>>>> I've to write the ds component descriptor by hand. We generallay
don't use
>>>>>>> objects but classes, having ds caring about creating and activating
the
>>>>>>> instances.
>>>>>> 
>>>>>> I am by no means a Scala expert (whatever you will say now, but I
am
>>>>>> just scared by the syntax ;-) )
>>>>>> 
>>>>>> So, coming back to the scr-plugin problem: The plugin (currently)
reads
>>>>>> the source files with the help of the QDox library. So I would assume
>>>>>> that the inability of the plugin to process Scala is related to this
>>>>>> situation.
>>>>>> 
>>>>>> If you would know of a tool to read Scala source files for consumption
>>>>>> by the plugin, you are welcome to guide us there (or even better
provide
>>>>>> a patch to use it ;-) ).
>>>>>> 
>>>>>> I think a similar problem exists for Groovy (and yes, it would be
nice
>>>>>> to have something there, too ;-) ).
>>>>> 
>>>>> In theory, you might be able to use annotations (i.e. "real"
>>>>> annotations, not JavaDoc/QDox annotations). I've been planning on
>>>>> trying this technique with Groovy and maven-scr-plugin, but I haven't
>>>>> had the time to try it out. Beyond the fact that I personally prefer
>>>>> to use @Component instead of @scr.component, it just like parsing
>>>>> Scala (or Groovy) sources is far more complex than using the
>>>>> reflection API. To be clear, this is still going to require surgery to
>>>>> the scrplugin code, I just have a feeling that the surgery is going to
>>>>> more like foot surgery than brain surgery (if this metaphor makes
>>>>> sense).
>>>> 
>>>> The point about having QDox also parse for the Annotations is, that the
>>>> Annotations are defined to not be added to the class files to not create
>>>> run-time dependencies and to not create class-file incompatibilities.
>>>> 
>>>> Now, you may say we were over-cautious in this respect and another
>>>> retention policy would be viable (in terms of not creating runtime
>>>> dependencies), e.g. CLASS or even RUNTIME.
>>>> 
>>>> If we can go with that, it should -- theoretically -- be possible to
>>>> actually read the annotations from the classes instead of using the QDox
>>>> parser.
>>>> 
>>>> Regards
>>>> Felix
>>>> 
>>>>> 
>>>>> Justin
>>>>> 
>>>>>> 
>>>>>> Regards
>>>>>> Felix
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> reto
>>>>>>> 
>>>>>>> On Sun, Aug 1, 2010 at 8:37 AM, Atle Prange <atle.prange@gmail.com>
wrote:
>>>>>>> 
>>>>>>>> Thank you for the replies, my journey can continue, although
with a sligth
>>>>>>>> blow to my self esteem, i thought i was an experienced programmer,
i guess
>>>>>>>> i
>>>>>>>> have to read more books....
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -atle
>>>>>>>> 
>>>>>>>> On Sat, Jul 31, 2010 at 11:02 PM, Christopher Brind <brindy@brindy.org.uk
>>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Have never used Scala myself, but Peter Kriens discussed
this in his blog
>>>>>>>>> recently:
>>>>>>>>> http://www.osgi.org/blog/2010/07/scala-components-vs-osgi.html
>>>>>>>>> 
>>>>>>>>> Hope it helps in some way.
>>>>>>>>> 
>>>>>>>>> Cheers,
>>>>>>>>> Chris
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 31 July 2010 21:58, Atle Prange <atle.prange@gmail.com>
wrote:
>>>>>>>>> 
>>>>>>>>>> Hi,
>>>>>>>>>> 
>>>>>>>>>> i am about to embark on a journey involving scala
and osgi. But it
>>>>>>>>> appears
>>>>>>>>>> to me (ref. my last question on this list regarding
static references)
>>>>>>>>> that
>>>>>>>>>> it might not be a good idea, since the otion of scala
objects actually
>>>>>>>>> are
>>>>>>>>>> implemented as singletons, and therefor never will
be cleaned up after
>>>>>>>> a
>>>>>>>>>> bundle is unloaded. Does anybody here have experience
with scala on
>>>>>>>> osgi,
>>>>>>>>>> and could give me a hint on this matter?
>>>>>>>>>> 
>>>>>>>>>> -atle
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>> 
>>>>>> 
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>> 
>> 
> 
> 
> 
> -- 
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message