Guillaume-
I know this to be true (and have seen it with my own eyes), but I can't
find where it's documented. Can you send me a link?
In any case, I agree with you that a mandatory package shouldn't be
created. Ideally, an optional one would be created for RUNTIME or CLASS,
but none for SOURCE.
Thanks,
Justin
On 11/19/10 11:05 AM, 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 <jus...@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 <fmesc...@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.pra...@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
>>>>>>>> <bri...@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.pra...@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-unsubscr...@felix.apache.org
>>>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
