Help building against AEM 6.1 beta (601_Load_19) | Community
Skip to main content
New Participant
October 16, 2015
Solved

Help building against AEM 6.1 beta (601_Load_19)

  • October 16, 2015
  • 12 replies
  • 3940 views

Hi,

I have been asked to build our AEM 6.0 commerce integration against the latest 6.1 beta code (601_Load_19), but I am having some trouble with it and was wondering if anyone could help me with some settings?

The error that I am getting when I try to build our plugins is:

Failed to execute goal org.apache.felix:maven-scr-plugin:1.17.0:scr (generate-scr-scrdescriptor) on project agilitypim.core: Execution generate-scr-scrdescriptor of goal org.apache.felix:maven-scr-plugin:1.17.0:scr failed: An API incompatibility was encountered while executing org.apache.felix:maven-scr-plugin:1.17.0:scr: java.lang.VerifyError: Constructor must call super() or this() before return
[ERROR] Exception Details:
[ERROR] Location:
[ERROR] com/adobe/cq/commerce/pim/common/AbstractImporter.<init>()V @1: return
[ERROR] Reason:
[ERROR] Error exists in the bytecode
[ERROR] Bytecode:
[ERROR] 0000000: 2ab1

I have updated my aem-api dependency to:

<dependency>
            <groupId>com.adobe.aem</groupId>
            <artifactId>aem-api</artifactId>
            <version>6.1.0-beta3</version>
 </dependency>

Was this the correct thing to do?  If I leave out the version tag, we get the 6.0.0.1 version of the aem-api which doesn't work with the 6.1 beta of AEM that we have - some of the commerce APIs are out of date.

Do I need to add extra code to the classes that are derived from AbstractImporter or is it that AbstractImporter is no longer using the inheritance feature of SCR, so I need to change my classes accordingly?  Or something else entirely?

Thanks,

Dan Tate

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by joerghoh

As you refer to AEM 6.1 beta, you should get in contact with Adobe support, as you are part of the AEM beta program.

Your case looks like you have corrupt artifacts in your local .m2 cache. Please purge and retry.

kind regards,
Jörg

12 replies

Dan_TateAuthor
New Participant
October 16, 2015

If you follow the instructions to use AEM as a repository, you can then go to turl:

http://localhost:4502/maven/repository/com/day/cq5-parent/0.0.1-SNAPSHOT/cq5-parent.pom

This will give you every jar that is used in the AEM and the version numbers.  You have to go into your pom, remove the dependency on the aem-api (cq-quickstart) and put in all the jars that you require individually (with the correct version numbers as recovered from the AEM).  Only then will you be able to build against it.

Hope that helps.

ronroth
New Participant
October 16, 2015

I think I've figured out what's going on. If you compare cq-quickstart-6.1.0-apis.jar with aem-api-6.0.0.1.jar in a java decompiler (e.g. http://jd.benow.ca/) you'll notice that the 6.1 version is trying to provide an "empty" API; i.e. all the logic has been removed and every class method returns null. I suppose this is meant to be the "interface" and then <scope>provided</scope> says that the AEM instance will provide the "implementation". 

However, there are some issues; e.g here's what I'm seeing:

public class ResourceWrapper
  implements Resource
{
  private final Resource resource;
  
  public ResourceWrapper(@Nonnull Resource paramResource) {}
  

The empty constructor causes this:

An API incompatibility was encountered while executing org.apache.felix:maven-

scr-plugin:1.20.0:scr: java.lang.VerifyError: Constructor must call super() or t
his() before return
[ERROR] Exception Details:
[ERROR] Location:
[ERROR] org/apache/sling/api/resource/ResourceWrapper.<init>(Lorg/apache/sling/a
pi/resource/Resource;)V @1: return
[ERROR] Reason:
[ERROR] Error exists in the bytecode
[ERROR] Bytecode:
[ERROR] 0x0000000: 2ab1

 

I'm sure there are many more similar errors. 

 

WORKAROUND:

set MAVEN_OPTS="-noverify"

With this turned off I can build with cq-quickstart-6.1.0-apis.jar. I'm trusting the AEM instance to provide the OSGI services anyway so I think this is ok.