adobe/aem-component-generator

Generator dependency/ Pre-requisite

Closed this issue · 9 comments

May I know what minimum version of AEM and acs commons is required for this to work? I tried to use component generator with AEM 6.6.3 and acs-aem-commons-content-3.14.12 there are few annotations that were not supported. I am getting error like follows:

com.adobe.acs.commons.models.injectors.annotation does not exist
[ERROR] symbol: class ChildResourceFromRequest
[ERROR] location: class com.company.components.impl.DemoCompImpl

I think README.md file should mention minimum requirements.

Hi @prahladmishra, thanks for the inquiry.

The component generator is definitely tested to work AEM 6.4+, but I would think it would still work with 6.3 provided you have the SP's for the sling model exporter support. Even w/o that, though, the option for sling model export could be turned off via config.

@ChildResourceFromRequest was first added to acs-aem-commons-4.2.0. It is used for child sling models for Image fields and Composite Multi-fields. I believe that is the only functionality dependent upon ACS AEM Commons.

I agree that some level of doc in the README would be a good idea.

I am having these exact same issues:

com.adobe.acs.commons.models.injectors.annotation does not exist
[ERROR] symbol: class ChildResourceFromRequest
[ERROR] location: class com.company.components.impl.DemoCompImpl

Running AEM 6.5.3 with a project built from the latest Archetype generator, and I am relatively new to this environment, so not sure why this would be happening unless it hasn't been fully vetted on AEM 6.5+

I found this resource to be useful in helping me to resolve this: https://adobe-consulting-services.github.io/acs-aem-commons/pages/maven.html

hi @SilverFox70 , thanks for chiming in. Generated code absolutely works on 6.5+. Per discussion above, @ChildResourceFromRequest is an annotation from ACS AEM Commons v4.2.0+.

If we think that the generator needs to option to toggle ACS AEM Commons dependency off (i.e. a project that cannot include ACS AEM Commons) then that would be a great PR for someone to submit.

I personally have worked on numerous AEM projects and have yet to work on one not using ACS AEM Commons, but if there are projects that are required to omit it then I could see that flag as being valuable. In those cases, child models (models within models) would not be supported. Technically we could use the AEM OOTB @ChildResource annotation but since it doesn't include the SlingHttpRequest in the injection most child models would fail.

For now I'll be sure to update the README in the next few days/week to make it clear that there is a dependency on ACS AEM Commons for the generated code.

Thank you for the follow-up @HitmanInWis. This tool will save me quite a bit of time, much appreciated.

Quick follow up: although most of the configuration worked without issue, the nested children for Image and Links do not show up at all (not present in the model.json). Is there a particular portion of acs-aem-commons which might be responsible for thiso rhave you encountered a similar issue?

My gut is that is has to do with the fact that I cannot set filevault-package-maven-plugin allowIndexDefinitions to true, because doing so results in the error:

[ERROR] ValidationViolation: "jackrabbit-packagetype: Package of type 'APPLICATION' is not supposed to contain Oak index definitions but has 'allowIndexDefinitions' set to true.", filePath=META-INF/vault/properties.xml

I look forward to the updated dependency documentation as that may clear up these remaining issues.

I feel like there's a few things being mixed together here that may not be relevant to each other.

Setting allowIndexDefinitions in your deployment package shouldn't at all be relevant to this tool, the submodels, or their export via model.json.

Regarding your first question about nested children for Image/Links not showing up at all (not present in the model.json) I can give that a quick test to see.

I tested just now, using the component generator with the example demo-config.json provided, and both of the sub-models (Image, Links) are indeed included in the .model.json if you have the following setting "content-exporter": true.

Screen Shot 2020-12-18 at 9 55 36 AM

LMK if you're still having troubles, and I'd be happy to jump on a screen share to help.

Originally requested issue (documentation on dependency of generated code on ACS AEM Commons) resolved by PR #45