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
