Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.
SOLVED

Help building against AEM 6.1 beta (601_Load_19)

Avatar

Level 1

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

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

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

View solution in original post

12 Replies

Avatar

Correct answer by
Employee Advisor

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

Avatar

Level 9

Can you please set maven logs to debug level, it may add some information to this error

Avatar

Level 1

We are have the exact same error, but with AEM 6.1 release and the following maven dependency:

<depen­dency>
   <groupId>com.day.cq</groupId>
   <arti­fac­tId>cq-quickstart</arti­fac­tId>
   <ver­sion>6.1.0</ver­sion>
   <scope>pro­vided</scope>
   <clas­si­fier>apis</clas­si­fier>
</depen­dency>

We've trying clearing our local repository to no avail.

We'd prefer not using AEM as the repository as suggested in the previous post.

Avatar

Level 2

I see the exact same issue

<dependency> <groupId>com.day.cq</groupId> <artifactId>cq-quickstart</artifactId> <version>6.1.0</version> <scope>provided</scope> <classifier>apis</classifier> </dependency>

 

I've tried deleting the repository, fetching other dependencies and plugins from maven central instead of adobe repos (where possible), updating all dependencies and plugins to the latest supported in AEM 6.1, updating maven to latest stable versions, updating java to latest stable versions, all to no avail.

 

Error is as follows:

 

[ERROR] Failed to execute goal org.apache.felix:maven-scr-plugin:1.21.0:scr (generate-scr-scrdescriptor) on project *REMOVED*: Execution generate-scr-scrdescriptor of goal org.apache.felix:maven-scr-plugin:1.21.0:scr failed: An API incompatibility was encountered while executing org.apache.felix:maven-scr-plugin:1.21.0:scr: java.lang.VerifyError: Constructor must call super() or this() before return [ERROR] Exception Details: [ERROR] Location: [ERROR] org/apache/sling/api/servlets/SlingSafeMethodsServlet.<init>()V @1: return [ERROR] Reason: [ERROR] Error exists in the bytecode [ERROR] Bytecode: [ERROR] 0x0000000: 2ab1 [ERROR] [ERROR] ----------------------------------------------------- [ERROR] realm =    plugin>org.apache.felix:maven-scr-plugin:1.21.0 [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy [ERROR] urls[0] = file:/Users/user/.m2/repository/org/apache/felix/maven-scr-plugin/1.21.0/maven-scr-plugin-1.21.0.jar [ERROR] urls[1] = file:/Users/user/.m2/repository/org/apache/maven/maven-archiver/2.2/maven-archiver-2.2.jar [ERROR] urls[2] = file:/Users/user/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar [ERROR] urls[3] = file:/Users/user/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0-alpha-7/plexus-archiver-1.0-alpha-7.jar [ERROR] urls[4] = file:/Users/user/.m2/repository/org/apache/felix/org.apache.felix.scr.generator/1.13.0/org.apache.felix.scr.generator-1.13.0.jar [ERROR] urls[5] = file:/Users/user/.m2/repository/org/ow2/asm/asm-all/5.0.2/asm-all-5.0.2.jar [ERROR] urls[6] = file:/Users/user/.m2/repository/org/osgi/org.osgi.core/4.2.0/org.osgi.core-4.2.0.jar [ERROR] urls[7] = file:/Users/user/.m2/repository/org/osgi/org.osgi.compendium/4.2.0/org.osgi.compendium-4.2.0.jar [ERROR] urls[8] = file:/Users/user/.m2/repository/org/sonatype/plexus/plexus-build-api/0.0.7/plexus-build-api-0.0.7.jar [ERROR] urls[9] = file:/Users/user/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.8/plexus-utils-1.5.8.jar [ERROR] Number of foreign imports: 1 [ERROR] import: Entry[import  from realm ClassRealm[project>*REMOVED*:*REMOVED*:2.4.1-SNAPSHOT, parent: ClassRealm[maven.api, parent: null]]] [ERROR]

Avatar

Level 1

Hi,

As I understand it, there's a bug in the bytecode of the AEM-API and the only way around it at the moment is to use the AEM as a repository.  I had hoped this issue would have been addressed before AEM 6.1 was released, but it doesn't look like it has been.

I followed this:

https://helpx.adobe.com/experience-manager/kb/HowToUseCQ5AsMavenRepository.html

To get mine to build, but I haven't progressed past 601_Load19 because I thought that this would be fixed for the release version.  I believe others have had a problem with later build of 6.1, so not sure it will work with the released one.

Dan Tate

Avatar

Level 1

Hi,

Thanks for replying.  When I set maven to debug logging I get the attached output.

I'm not sure if that's much more help, but if you can tell something from it, I'd really appreciate it.

Thanks,

Dan

Avatar

Level 1

I am also seeing the same error with 

<depen­dency>
   <groupId>com.day.cq</groupId>
   <arti­fac­tId>cq-quickstart</arti­fac­tId>
   <ver­sion>6.1.0</ver­sion>
   <scope>pro­vided</scope>
   <clas­si­fier>apis</clas­si­fier>
</depen­dency>

I have tried maven-scr-plugin versions 1.19.0, 1.20.0, 1.21.0. 

I have also tried clearing the .m2 repository with no success. 

Avatar

Level 1

Hi,

 

I've had it recommended to me that I use the cq5-archiva-servlet to build directly against the AEM 6.1 jar, but it fails to serve up some of the jar files (aem-api being one of them!).  Has anyone else tried this and had success?

 

Thanks

Dan

Avatar

Level 1

I can get past the bytecode error by adding the sling dependency directly to the plugin definition. But it just opens a rabbit hole of further build errors. 

 

                <plugin>
                    <groupId>org.apache.felix</groupId>
                    <artifactId>maven-scr-plugin</artifactId>
                    <version>1.20.0</version>

...

                    <dependencies>
                        <dependency>
                            <groupId>org.apache.sling</groupId>
                            <artifactId>org.apache.sling.api</artifactId>
                            <version>2.8.0</version>
                        </dependency>
                    </dependencies>
                </plugin>

Avatar

Level 1

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.

Avatar

Level 1

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. 

Avatar

Level 3

I'm going to post this here in case people find this thread before they find mine.

This issue is caused by the obfuscator that has been run on the AEM 6.1 uber-jar.  That obfuscator removes methods that the Java 1.8 bytecode verifier needs to be there. If you request the unobfuscated jar from support, and compile against that, these errors disappear.

I have a support ticket open to request that they adjust the obfucsator settings to prevent this from happening.