I am facing issues while trying to include cassandra dependency in my project's pom.xml.
Some problems were encountered while processing the POMs: [ERROR]
Failed to determine Java version for profile doclint-java8-disable #
com.datastax.cassandra:cassandra-driver-parent:2.1.6,
/root/.m2/repository/com/datastax/cassandra/cassandra-driver-parent/2.1.6/cassandra-driver-parent-2.1.6.pom,
line 92, column 14
I have tried googling but no success there.
Up till cassandra-driver-core-2.1.2, build gets completed without any error. But when I try building with version 2.1.6 though the build completes successfully the cassandra-driver-parent pom breaks as highlighted above, thus preventing me from importing the required classes.
This is my pom entry:
<!-- Cassandra Dependency -->
<dependency>
<groupId>com.datastax.cassandra</groupId>
<artifactId>cassandra-driver-parent</artifactId>
<version>2.1.6</version>
<type>pom</type>
</dependency>
<dependency>
<groupId>com.datastax.cassandra</groupId>
<artifactId>cassandra-driver-core</artifactId>
<version>2.1.6</version>
</dependency>
The offending profile is declared as this in com.datastax.cassandra:cassandra-driver-parent:2.1.6 :
<profiles>
<profile>
<id>doclint-java8-disable</id>
<activation>
<jdk>[1.8,)</jdk> <!-- This is line 92 -->
</activation>
<properties>
<javadoc.opts>-Xdoclint:none</javadoc.opts>
</properties>
</profile>
</profiles>
It seems that your Maven installation is unable to determine which Java version you are running. The syntax is correct and should work (even if it wasn't, you wouldn't be able to do much about it).
You could try disabling the automatic profile activation through the command line:
-P !doclint-java8-disable
Related
I am novice when it comes to maven and spring boot. I need to run a spring boot project based on the profile. By default, the scope of following dependency is test which throws error at run time if I want to use h2. As I am not allowed to change the scope, I thought of adding two profiles in pom.xml - one default to be active by default and one for the h2 dependency without scope as test.
Following is what I added to pom.xml -
<profiles>
<profile>
<id>default</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<dependencies>
<dependency>
<groupId>com.h2database</groupId>
<artifactId>h2</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
</profile>
<profile>
<id>automation</id>
<properties>
<env>automation</env>
</properties>
<dependencies>
<dependency>
<groupId>com.h2database</groupId>
<artifactId>h2</artifactId>
</dependency>
</dependencies>
</profile>
</profiles>
Now, I tried to run my project using following command -
mvn -D "spring-boot.run.profiles=automation" -DskipTests=true spring-boot:run
But I still see the same h2 dependency scope error that I was seeing earlier.
Caused by: java.lang.IllegalStateException: Cannot load driver class: org.h2.Driver
i.e. I am unable to change the scope of dependency this way. What am I missing here?
You are defining a Maven profile, but activating a Spring profile. Use the following syntax:
mvn groupId:artifactId:goal -P profile-1,profile-2
https://maven.apache.org/guides/introduction/introduction-to-profiles.html
Update
I tested the configuration you posted, and spring-boot:run fails for me if only default profile is active with the follwoing exception:
java.lang.IllegalStateException: Cannot load driver class: org.h2.Driver
You can check your dependencies with
mvn dependency:tree
The output of above command varies according to maven profiles passed in.
Thanks to a separate thread, I realized my project's uber-jar had a bug. I create the uber-jar using maven-shade-plugin because I need the more advanced transformer capabilities to merge several ServiceLoader definitions.
So, the issue is that my project has a system-scope compile-time dependency on tools.jar, locating tools.jar on the local machine relative to the value of the java.home sysprop. The bug is that I didn't realize this dependency was:
leaking into the dependency-reduced pom.xml of the uber-jar, and
even worse, the pattern ${java.home} in the dependency definition was being resolved and hard-coded into the uber-jar's POM. This second part was particularly embarrassing as it reveals the JDK location of the build machine (see line 50 here).
To workaround this problem, I conditionally disabled the profile which created the dependency. All details below are in the <activation> section:
Before:
<profile>
<id>internal.tools-jar</id>
<activation>
<file>
<exists>${java.home}/../lib/tools.jar</exists>
</file>
</activation>
<dependencies>
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
<version>1.8.0</version>
<scope>system</scope>
<systemPath>${java.home}/../lib/tools.jar</systemPath>
</dependency>
</dependencies>
</profile>
After:
<profile>
<id>internal.tools-jar</id>
<activation>
<jdk>1.8</jdk>
<file>
<missing>src/main/java/systems/manifold/Dummy.java</missing> <!-- this file is only present in the uber-jar module, therefore exclude if present -->
</file>
</activation>
<dependencies>
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
<version>1.8.0</version>
<scope>system</scope>
<systemPath>${java.home}/../lib/tools.jar</systemPath>
</dependency>
</dependencies>
</profile>
So, after all that, my question is: is this the best way to prevent this system-scoped dependency from leaking into the uber-jar's dependency-reduced pom.xml?
Thanks in advance,
Kyle
Updated 2018-02-16:
Unfortunately the following configuration in the shade plugin doesn't prevent the system-scope dependency from leaking:
<artifactSet>
<excludes>
<exclude>*</exclude>
</excludes>
</artifactSet>
to the shade plugin's configuration but the resolved system scope dependency still shows up in the POM. Puzzling!
I have the below in my POM file:
<properties>
<main.basedir>${project.basedir}/..</main.basedir>
<jettyVersion>9.2.3.v20140905</jettyVersion>
<jersey.version>2.15</jersey.version>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
When I run mvn install getting this error with regards to versioning:
The following artifacts could not be resolved: org.glassfish.jersey.container:jersey-container-servlet:jar:9.2.3.v20140905
Correctly pointed by #Steve C in the comments, you seem to be using incorrect property name as the value of the version for jersey-container-servlet. The version as specified in the error jersey-container-servlet: jar:9.2.3.v20140905 doesn't exist as seen here. You can make sure the version used is either:
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>2.15</version>
</dependency>
or use your defined property jersey.version as:
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>${jersey.version}</version>
</dependency>
We have product help document which is about 150Mb and being build every day and updated to maven repo.
So when we build the project which has dependency on help document it will download entire 150Mb once everyday and it takes lot of time.
Is there any way to avoid it?
Like give an entry in pom.xml
<properties>
<download.docmodule>true</download.docmodule>
</properties>
And in users settings.xml
<download.docmodule>false</download.docmodule>
And use this attribute to stop downloading the document?
Basically I want CI server to download it and package it but want developers not to waste time and bandwidth downloading it
<dependency>
<groupId>docmodules</groupId>
<artifactId>projname</artifactId>
<version>${documentation.version}</version>
<classifier>resources</classifier>
<type>zip</type>
<scope>provided</scope>
</dependency>
You can use profiles like:
<profiles>
<profile>
<id>donloadHelp</id>
<dependencies>
<dependency>
//Add your dependency
</dependency>
</dependencies>
</profile>
</profiles>
The help will only downloaded if you activate the profile in maven.
To activate the profile, you have to call
mvn <target> -PdownloadHelp
I have some dependencies in my webapp that I've marked as provided because I expect them to be provided by an appserver (maybe a production environment provides these dependencies at the specified versions). How do I simulate that when I'm running tests or in development on my localhost using for example the tomcat7-maven-plugin goals like run?
I can't see any way to do it without manually copying jars around. I can see how to use the test classpath - is there something wrong with what I'm trying to do?
OK, I've found a way of getting this to work - it's reasonable but there's a duplication of dependency information and a magic profile... I feel that the tomcat7-maven-plugin should provide a means of making provided dependencies available in the container when running.
Add a profile that is activated when the tomcat plugin runs, and add the dependencies that have provided scope with compile scope to that profile, eg.
... in project pom ...
<dependencies>
<dependency>
<groupId>com.mycompany</groupId>
<artifactId>my-provided-artifact</artifactId>
<version>1.2.3</version>
<scope>provided</scope>
</dependency>
</dependencies>
...
<profiles>
<profile>
<!-- profile activated as cli param when tomcat7 plugin runs -->
<id>tomcat</id>
<dependencies>
<dependency>
<groupId>com.mycompany</groupId>
<artifactId>my-provided-artifact</artifactId>
<version>1.2.3</version>
<scope>compile</scope>
</dependency>
</dependencies>
</profile>
</profiles>
I use, for example, this:
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.0</version>
<configuration>
<path>/myApp</path>
</configuration>
<dependencies>
<dependency>
<groupId>com.oracle</groupId>
<artifactId>ojdbc6</artifactId>
<version>11.2.0.3</version>
</dependency>
</dependencies>
</plugin>
and then also include the dependency again later with provided.