search

wttech / gradle-aem-plugin

Swiss army knife for Adobe Experience Manager related automation. Environment setup & incremental AEM application build which takes seconds, not minutes.
https://tech.cognifide.com/tag/gradle-aem-plugin
Apache License 2.0
158 stars 32 forks source link

SCR annotations support #82

Closed michalwronowski closed 6 years ago

michalwronowski commented 6 years ago

SCR annotations are not supported but should be. AEM is tightly coupled with Felix thus support for Felix SCR annotations is crucial. Raising awareness of lack of support as in #72 should not be the way to go.

Actual behaviour:

Manifest does not contain any entries for classes annotated with SCR annotations.

Expected behaviour:

Proper Manifest generating logic for classes annotated with SCR annotations is present.

pun-ky commented 6 years ago

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.

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.

pun-ky commented 6 years ago

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.

michalwronowski commented 6 years ago

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.

pun-ky commented 6 years ago

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.

pun-ky commented 6 years ago

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.