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
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
