What's aopalliance all about? And why is guice using it? - aop

I'm using guice for dependency injection with aop from aopalliance. I can't quite figure out what's aopalliance all about and who implemented the version (dated from 2004) that's on their sourceforge page. Why is guice using this version instead of a more known package such as AspectJ?
Also, do you know of any tutorials on the aopalliance version?
Thanks

AOP Alliance is a set of interfaces that multiple frameworks implement (see AOP Alliance Motivations), including both Guice and Spring.
AOP Alliance was chosen for Guice because it has a high capability and a simple API.
The Guice wiki has an AOP guide.

Related

Java Bean Mapper Framework in Spring

I am planning to use MapStruct as Java Bean Mapper Library into my project. But before choosing this, I would like to see any such library is there in the Spring framework. I could not able to find such, Can anyone confirm do we have any such library? If not, is MapStruct is the good option to use along with other Spring Framework libraries?

Any OpenJDK equivalent to JRockit's Weaving/AOP API?

I'm rather impressed by what I see of JRockit's built-in weaving/AOP support. Is there any similarly-easy-to-use support for AOP weaving on OpenJDK?
The code I am trying to instrument is often loaded via Maven, so hooking in to classloaders to e.g. install a weaving classloader may be difficult. A JMTI-based solution may or may not be practical.

Using Google Guice within Eclipse plugins

Is there a comprehensive discussion of the approaches of using Google Guice in the context of Eclipse plugins? There is the Peaberry project that targets OSGi containers in general, but this seems not to be used much in production plugin projects, which makes me a bit skeptic to use it (someone correct me if I'm wrong).
The complete Xtext and Xtend wiring is done with Guice. This includes the non-Eclipse relevant parts but also the Eclipse plugins and UI components.

Mocking framework for osgi/eclipse applications?

I am looking for mocking framework to use in my osgi/eclipse test fragments. I have looked at:
http://www.jmock.org/download.html
but since its not osgi I need to convert it manually. I have tried to google for some mocking frameworks that works with osgi out of the box but have not been able to find any, does osgi developers not use mocking?
One solution will be to create mock objects of OSGi objects (like BundleContext and ServiceReference). You can use any mocking framework for this and of course you don't have to run the test in an OSGi container. This will be OK for simple scenarios.
If you want to test inside a container, you have the following options:
Pax-Exam
Spring DM Testing facilities
Actually Mockito works quite good with OSGI applications, since it has OSGI manifest. You can simply add it to your target platform from the latest orbit repository. I managed to make Powermock also working for Eclipse Plugins and it is available as well as update site at https://code.google.com/p/powermock-osgi/

Using Enunciate with Grails

I am creating Web APIs, in a RESTful manner. Grails of course has good support for creating REST web services. Enunciate claims to help in the API part, where things like documentation, client libraries, etc are important.
The purpose of this post is to invite experiences on using Enunciate with Grails, or ideas on how that can be done.
There are two main issues using them together:
Enunciate works with JAX-RS, not the native implementation of REST by Grails. Thankfully there's a JAX-RS plugin available, but am not sure if Enunciate will be able to work with it.
Grails domain classes are in Groovy while Enunciate works with Java
source code (example).
Enunciate works with both Java source code and Java compiled bytecode to do its work. But if you don't have Java source code, Enunciate won't be able to pull stuff out of your JavaDocs to enhance its generated documentation. Given that, there should (theoretically) be a way to apply Enunciate to compiled Groovy bytecode, but your docs won't be as rich because Enunciate won't be able to see your JavaDoc documentation. I say theoretically because I don't have any personal experience with it nor do I know how painful it is to pull off.
There is an open issue at ENUNCIATE-356 to investigate this complexity. Note that ENUNCIATE-356 depends on ENUNCIATE-584, which might get some more traction soon, being driven by ENUNCIATE-585 as we move from using APT (introduced in Java 5, deprecated in Java 7) to the Javac tool (introduced in Java 6). It would be interesting to know whether the Javac tool supports languages other than Java, in which case we'd get Groovy support for free.