We Keep Coding

AWS Lambda Jar unable to zip after adding selenium dependencies in pom

This is a weird error. After adding the selenium dependencies to the pom of my maven project and upload it to a lambda, it says it is unable to unzip the file. However after removing the dependencies, the lambda is able to unzip the file just fine (however it comes up with a class not found afterwards). I have tried removing the dependencies one by one but each one triggers the error.
Any ideas on how to solve this?
Class not found error
org/openqa/selenium/WebDriver: java.lang.NoClassDefFoundError
java.lang.NoClassDefFoundError: org/openqa/selenium/WebDriver
lambda cannot zip error
Calling the invoke API action failed with this message: Lambda was not able to unzip the file
The dependencies causing the issue
<dependency>
<groupId>org.seleniumhq.webdriver</groupId>
<artifactId>webdriver-common</artifactId>
<version>0.9.7376</version>
</dependency>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-chrome-driver</artifactId>
<version>3.141.59</version>
</dependency>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>3.141.59</version>
</dependency>
updated dependancies (for Vishal)
<dependency>
<groupId>org.seleniumhq.webdriver</groupId>
<artifactId>webdriver-common</artifactId>
<version>0.9.7376</version>
</dependency>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-chrome-driver</artifactId>
<version>3.141.59</version>
</dependency>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>3.141.59</version>
</dependency>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-api</artifactId>
<version>2.0rc2</version>
</dependency>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-remote-driver</artifactId>
<version>3.141.59</version>
</dependency>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-support</artifactId>
<version>3.141.59</version>
</dependency>
Configuration
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.6.0</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
<encoding>UTF-8</encoding>
<forceJavacCompilerUse>true</forceJavacCompilerUse>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>

The shade plugin combines all dependencies with the developed code and plops them in one Uber JAR. The downside is that it can overwrite resource files, and doesn't play well with signed jars (in my experience at least).
I would recommend moving away from the shade plugin if at all possible.
That said, if you have to use it - you're issue may be with the combining the jar resources. There are many transformers that you can use to resolve this, and you'll need to investigate which one is really needed. I would start with something like this
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.4.3</version>
<configuration>
<shadedArtifactAttached>true</shadedArtifactAttached>
<shadedClassifierName>${executable.classifier}</shadedClassifierName>
<filters>
<filter>
<artifact>*:*</artifact>
<excludes>
<exclude>META-INF/*.SF</exclude>
<exclude>META-INF/*.DSA</exclude>
<exclude>META-INF/*.RSA</exclude>
</excludes>
</filter>
</filters>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<transformers>
<transformer
implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer" />
<transformer
implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<mainClass>fully.qualified.ClassName</mainClass>
</transformer>
</transformers>
</configuration>
</execution>
</executions>
</plugin>
You can find more tranformers on the Apache plugin here
The alternative that I would suggest is Spring Boot, which uses the Jar-in-Jar structure with a custom ClassLoader to load classes from the internal jar(s).
This is the easier method due to not having to re-write files as the Shade plugin approach and it handles the dependencies a little better.
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>1.3.6.RELEASE</version>
<configuration>
<classifier>${executable.classifier}</classifier>
<layout>ZIP</layout>
<mainClass>fully.qualified.ClassName</mainClass>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
Seriously, look at the simpler configuration!
NOTE: Most of this came from my own notes - version numbers may be a little old...

Try to tell your dependencies to output zip, maybe jar is messing up with things
Add this to maven-assembly-plugin configuration:
<formats>
<format>zip</format>
</formats>
For example:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
...
<configuration>
...
<formats>
<format>zip</format>
</formats>
</configuration>
</plugin>
Same is suggested here

I figured it out. The java selenium seemed to cause the major issue. Downgrading to 3.10 fixed the issue although I have no idea why.

Maven AspectJ plugin fails to build with Java 9 due to missing tools.jar

I switched my JDK version from 8 to 9 and the AspectJ plugin no longer works due to missing tools.jar:
Execution default of goal org.codehaus.mojo:aspectj-maven-plugin:1.10:compile failed: Plugin org.codehaus.mojo:aspectj-maven-plugin:1.10 or one of its dependencies could not be resolved: Could not find artifact com.sun:tools:jar:9.0.1 at specified path C:\Program Files\Java\jdk-9.0.1/../lib/tools.jar
I understand that tools.jar (and rt.jar) were removed from Java 9 JDK. I am wondering if there a way to get Maven AspectJ plugin to work with Java 9 without tools.jar?
Here is my plugin definition with version info:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.10</version>
<configuration>
<encoding>${project.build.sourceEncoding}</encoding>
<complianceLevel>1.9</complianceLevel>
<showWeaveInfo>true</showWeaveInfo>
<XnoInline>true</XnoInline>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>test-compile</goal>
</goals>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjrt</artifactId>
<version>1.9.0.RC2</version>
</dependency>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjtools</artifactId>
<version>1.9.0.RC2</version>
</dependency>
</dependencies>
</plugin>

I just found an ugly trick to make aspectj working with Java 9, just point com.sun:tools to the pom.xml and the compiler just run.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.11</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>test-compile</goal>
</goals>
<configuration>
<source>1.8</source>
<target>1.8</target>
<complianceLevel>1.8</complianceLevel>
<encoding>UTF-8</encoding>
<verbose>true</verbose>
<weaveDependencies>
<weaveDependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-netty</artifactId>
</weaveDependency>
</weaveDependencies>
<showWeaveInfo>true</showWeaveInfo>
<XnoInline>true</XnoInline>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjrt</artifactId>
<version>${aspectj.version}</version>
</dependency>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjtools</artifactId>
<version>${aspectj.version}</version>
</dependency>
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
<version>${java.version}</version>
<scope>system</scope>
<systemPath>${project.basedir}/pom.xml</systemPath>
</dependency>
</dependencies>
</plugin>

Until version 1.11.1 is released into Maven Central by org.codehaus.mojo use the snapshot build instead:
<groupId>com.github.m50d</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.11.1</version>

Ran into the same issue, the problem is that this transitive dependency is active by default in the aspectj-maven-plugin.
Fixed it for me with this PR
https://github.com/mojohaus/aspectj-maven-plugin/pull/35

Have you checked the newest plugin version?
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.11</version>

Adding AspectJ to pom.xml changed Java version with Maven, why?

UPDATE: here is my maven-compiler-plugin configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
I work on a multi-project application that I build with Maven. We decided to add AspectJ so I added the following code to pom.xml in the top level project: (from the official documentation)
<project>
...
<dependencies>
...
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjrt</artifactId>
<version>1.7.3</version>
</dependency>
...
</dependencies>
...
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<goals>
<goal>compile</goal> <!-- use this goal to weave all your main classes -->
<goal>test-compile</goal> <!-- use this goal to weave all your test classes -->
</goals>
</execution>
</executions>
</plugin>
...
</plugins>
<build>
...
</project>
and the following fragments to each subordinate projects:
</project>
...
<build>
....
<plugins>
...
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
<dependencies>
...
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjrt</artifactId>
</dependency>
....
</dependencies>
...
</project>
Somehow this modification has overridden the Java version I use. If I run build I get multiple errors like this:
Syntax error, annotations are only available if source level is 1.5 or greater
That gives me the suspicion that my Java version (originally 1.6) was somehow reverted to 1.4. I did nothing - at least not knowingly - that could influence the Java version, so I suspect that the above mentioned AspectJ related code is responsible for the change.
My question is how can AspectJ change the Java version and what should I do to fix this problem. Or do I misunderstand something completely and am I on the wrong track?

I think the problem is with the default source, target and complianceLevel settings of the aspectj-maven-plugin (according to the documentation linked previously, 1.4, 1.2 and 1.4 respectively). You should set these explicitly in your parent pom:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.5</version>
<!-- new configuration is here -->
<configuration>
<complianceLevel>1.6</complianceLevel>
<source>1.6</source>
<target>1.6</target>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>test-compile</goal>
</goals>
</execution>
</executions>
</plugin>
...
</plugins>
<build>

I was missing
<complianceLevel>${java.level}</complianceLevel>
in my pom.xml

If you don't have define the version, the compiler plugin assumes that your Java source conforms to Java 1.3 and that you are targeting a Java 1.1 JVM.
Maybe, you should define it:
http://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html

You can find last versions of dependecy and plugin for aspectj.

I was missing the java version with jdk version at the top of my pom properties.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.2</version> <!-- 1.5 dint work for me -->
<dependencies>
<!-- You must use Maven 2.0.9 or above or these are ignored (see MNG-2972) -->
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjrt</artifactId>
<version>${aspectj.version}</version>
</dependency>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjtools</artifactId>
<version>${aspectj.version}</version>
</dependency>
</dependencies>
<executions>
<execution>
<phase>process-sources</phase> <!-- or any phase before compile -->
<goals>
<goal>compile</goal>
<goal>test-compile</goal>
</goals>
</execution>
</executions>
<configuration>
<outxml>true</outxml>
<source>${jdk.version}</source> <!-- I was missing this -->
<target>${jdk.version}</target> <!-- jdk.version property -->
</configuration>
</plugin>
and at the top of my pom.xml I had set jdk.version property like,
<properties>
<jdk.version>1.7</jdk.version>
</properties>

Eclipse, QueryDSL and Spring Roo working together?

I'm trying to set up a maven-based SpringRoo project with QueryDSL in Eclipse and cannot seem to get the generator working when I have Roo enabled. If I create a plain project, and populate my pom.xml with the necessary querydsl plugins/dependencies, my metamodel classes are automatically generated.
However, if I switch to a basic ROO project, and add the necessary querydsl plugins/dependencies, then no metamodel classes are generated.
These are the additions I've put in my pom.xml:
<!-- Querydsl -->
<dependency>
<groupId>com.mysema.querydsl</groupId>
<artifactId>querydsl-core</artifactId>
<version>${querydsl.version}</version>
</dependency>
<dependency>
<groupId>com.mysema.querydsl</groupId>
<artifactId>querydsl-apt</artifactId>
<version>${querydsl.version}</version>
</dependency>
<dependency>
<groupId>com.mysema.querydsl</groupId>
<artifactId>querydsl-jpa</artifactId>
<version>${querydsl.version}</version>
</dependency>
<plugin>
<!-- Requires mysema m2e plugin (http://ilx.github.com/m2e-querydsl/repository/0.0.5/) -->
<groupId>com.mysema.maven</groupId>
<artifactId>maven-apt-plugin</artifactId>
<version>1.0.4</version>
<executions>
<execution>
<goals>
<goal>process</goal>
</goals>
<configuration>
<logOnlyOnError>true</logOnlyOnError>
<outputDirectory>target/generated-sources/apt</outputDirectory>
<processor>com.mysema.query.apt.jpa.JPAAnnotationProcessor</processor>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>com.mysema.querydsl</groupId>
<artifactId>querydsl-apt</artifactId>
<version>${querydsl.version}</version>
</dependency>
<dependency>
<groupId>com.mysema.querydsl</groupId>
<artifactId>querydsl-jpa</artifactId>
<classifier>apt</classifier>
<version>${querydsl.version}</version>
</dependency>
</dependencies>
</plugin>
<!-- right now this seems needed -->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>target/generated-sources/apt</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
I am using Eclipse 3.7, m2e 1.2, Java 6. I also have the mysema m2e plugin installed from http://ilx.github.com/m2e-querydsl/repository/0.0.5/.
Does anyone have a working configuration with Roo and QueryDSL that works? If so, can you share your pom.xml please?
Thanks,
Eric

com.mysema.query.apt.jpa.JPAAnnotationProcessor needs javax.persistence.Entity annotated Java files. If you use other annotations or add the Entity annotation at runtime, no classes will be generated.
See this chapter of the Querydsl reference docs for classloader based code generation as an alternative to APT http://www.querydsl.com/static/querydsl/2.8.2/reference/html/ch03s02.html

For some reason that I do not understand, I needed to add a spring-tx dependency to my pom.xml. Once that was in place, the metamodel classes were automatically generated. There was a caveat however, I needed to manually annotate my entities with #Entity and not rely on Roo to annotate it via aspects. Finally, updating my plugin to 1.0.7 removed the need to use maven-build-helper.
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-tx</artifactId>
<version>${spring.version}</version>
</dependency>
<!-- QueryDSL plugin -->
<plugin>
<!-- Requires mysema m2e plugin (http://ilx.github.com/m2e-querydsl/repository/0.0.5/) -->
<groupId>com.mysema.maven</groupId>
<artifactId>apt-maven-plugin</artifactId>
<version>1.0.7</version>
<executions>
<execution>
<goals>
<goal>process</goal>
</goals>
<configuration>
<outputDirectory>target/generated-sources/apt</outputDirectory>
<processor>com.mysema.query.apt.jpa.JPAAnnotationProcessor</processor>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>com.mysema.querydsl</groupId>
<artifactId>querydsl-apt</artifactId>
<version>${querydsl.version}</version>
</dependency>
<dependency>
<groupId>com.mysema.querydsl</groupId>
<artifactId>querydsl-jpa</artifactId>
<classifier>apt</classifier>
<version>${querydsl.version}</version>
</dependency>
</dependencies>
</plugin>
Sample Java Bean:
#RooJavaBean
#RooToString
#RooJpaEntity
#Entity
public class Client {
#Temporal(TemporalType.TIMESTAMP)
#DateTimeFormat(style = "M-")
private Date created_on;
private String name;
}

There's old discussion about this topic, where Ken Rimple states that " I had trouble getting anything to work on the QueryDSL generators with the pre-built ITDs. Since the actual class doesn't have an #Entity on it (until the AspectJ compiler comes in and adds it) when the QueryDSL is generating code, it doesn't see them as entities."
http://www.manning-sandbox.com/thread.jspa?threadID=51012&tstart=15
To me this seems to be something one could try to tweak by changing order in which maven is using plugins (lifecycle phases).

How to enable aspectj compile time weaving with Java 7 and maven

I have a project which currently works with java 6 and compile time weaving.
We use the following pom to enable spring aspects and our own ones:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.4</version>
<configuration>
<showWeaveInfo>true</showWeaveInfo>
<source>1.6</source>
<target>1.6</target>
<Xlint>ignore</Xlint>
<complianceLevel>1.6</complianceLevel>
<encoding>UTF-8</encoding>
<verbose>false</verbose>
<aspectLibraries>
<aspectLibrary>
<groupId>org.springframework</groupId>
<artifactId>spring-aspects</artifactId>
</aspectLibrary>
</aspectLibraries>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>test-compile</goal>
</goals>
</execution>
</executions>
</plugin>
I've tried various configuration but can't make it work with java 7.
If someone could share a working pom or leads it would be great.

After moving to version 1.7.0 of the aspectjtools it works fine. In addition you need to pass the compiler the version parameter as -1.7 (using the target parameter caused problems). If someone needs more details leave a comment and I'll add more configuration specific information.
You can take a working example from here: Spring, AspectJ and Maven example
Here is the working plugin definition from the pom (compiler-version="1.7", aspectj.version="1.7.0")
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.4</version>
<configuration>
<showWeaveInfo>true</showWeaveInfo>
<source>${compiler.version}</source>
<target>${compiler.version}</target>
<Xlint>ignore</Xlint>
<complianceLevel>${compiler.version}</complianceLevel>
<encoding>UTF-8</encoding>
<verbose>false</verbose>
<aspectLibraries>
<aspectLibrary>
<groupId>org.springframework</groupId>
<artifactId>spring-aspects</artifactId>
</aspectLibrary>
</aspectLibraries>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>test-compile</goal>
</goals>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjrt</artifactId>
<version>${aspectj.version}</version>
</dependency>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjtools</artifactId>
<version>${aspectj.version}</version>
</dependency>
</dependencies>
</plugin>