SCR annotations support about gradle-aem-plugin HOT 5 CLOSED

Currently you have to use separate SCR plugin to cover it. This will not be a part of AEM plugin any longer due to instability. Take a look at neva/gradle-scr-plugin (at my private repo).

It is recommended to use standarized OSGi annotations in new projects. Gradle AEM plugin usage is not designed to be used in existing projects due to problems with understanding Gradle after using Maven by developers. Basing on my experience, such practice ends with bad Gradle reputation and bad practices being introduced because many times Maven approaches could not be mapped 1 to 1 to Gradle. Such mappings could be done even simpler by doing it in a completely different way.

To sum up, lacking support is intentional but could be covered separately by one of external plugins.

• https://plugins.gradle.org/plugin/neva.scr
• https://github.com/janvolck/gradle-scr-plugin
• or even without any plugin: https://chanchal.wordpress.com/2011/07/26/using-gradle-to-build-an-osgi-bundle-supporting-scr-annotations/

As I know, both plugins (Neva's and Janvolck's) have defect related with descriptors not being regenerated sometimes. I know the fix and it was included when SCR was a part of AEM plugin. If you are really stucked, I can fix and release Neva's plugin especially for you so you will be unblocked, but you will be must be aware of that SCR generator has strange internal issue with compile classpath. Still better than using SCR I am recommending to just update your annotations, because adoption to new standard is very easy and does not take a lot of time. I have been close to 2 such migrations and generally they ended without serious problems.

from gradle-aem-plugin.

about

AEM is tightly coupled with Felix thus support for Felix SCR annotations is crucial.

agree, but in detail, Felix consists of Declarative Services. SCR is just a form of managing OSGi services like iPojo (http://felix.apache.org/documentation/subprojects/apache-felix-ipojo.html) or Blueprint (http://aries.apache.org/modules/blueprintannotation.html) . In AEM 6.2 there is upgraded Felix with Declarative Services in version 1.3 which is backward compatible (http://njbartlett.name/2015/08/17/osgir6-declarative-services.html). So I am definitely concinved that as you said, SCR annotations are not crucial, because there are so many alternatives.

If you could adapt your project for completely new technology like Gradle, you could probably also adapt your code to new form of same thing, like registration of OSGi services. I thinking here in case of openness for new technologies.

from gradle-aem-plugin.

It is not the matter of not being able to adapt to new standard, what as you wrote is indeed trivial.
It is the matter of being consistent with the standard present on the platform we are developing on.

If it is not a big deal for you to release fixed version of Neva's plugin, please do so. I'll gladly try it out.
I'm also open for discussion about that strange internal issue just to assess the risk of using the plugin.

from gradle-aem-plugin.

On Mon when I'll back from my free time I'll do my best and try to release it for you.

As I said earlier, Gradle plugin is designed to be used by new projects which are using AEM >= 6.2, so they should use new standard. When still fallback exists, then some devs couldn't even know that new standard exists and trick will just cause that they have to use it in a proper way. That approach really gives value, because code becomes more AEM agnostic and could be even ported to other platforms based on OSGi. If there was some reason or feature that SCR have, but OSGi annotations (parsed by BND tool) haven't, then I will agree with you that missing SCR is really crucial, but as I know it just isn't.

from gradle-aem-plugin.

as mentioned earlier, SCR support will be no longer part of AEM plugin project so I am closing that issue as it is descoped. I will inform you about changes in Neva SCR plugin personally.

from gradle-aem-plugin.