There is something I don't understand with maven and I didn't find any answer out there. So I ask it here, hoping to get an answer.
I added a jar as a maven dependency for a project as system scope.
When I run analyze-only goal on dependency plugin, it does find it. But whenever I want to use classes located in default package in this jar, it won't compile.
I did the same with a jar from same provider with same classes but this time located in one package other than default and it compiles.
Is there something obvious I missed or has someone already encountered the same problem ?
It is not worth posting the code as I just try to import one of the class of system dependency.
My POM (system dependency)
<?xml version="1.0" encoding="UTF-8"?>
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>edu.algo</groupId>
<artifactId>algorithms</artifactId>
<version>1.0</version>
<properties>
<lib.path>C:/lib</lib.path>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>edu.princeton.cs</groupId>
<artifactId>stdlib</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${lib.path}/stdlib/stdlib.jar</systemPath>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.6</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.5.1</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
</plugins>
</build>
</project>
Sorry to bother you guys and thanks for your help.
I found the answer to my question and it has nothing to do with maven. You just cannot import classes in default package from named package for java versions above 1.4, I was using 1.7 version for compilation.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4989710
Have you supplied the JAR it's looking for? It sounds like it can't find the JAR against which to compile against.
Have you read this?
http://docs.codehaus.org/display/MAVENUSER/Dependency+Scopes
It states:
system: This dependency is required in some phase of your project's
lifecycle, but is system-specific. Use of this scope is discouraged:
This is considered an "advanced" kind of feature and should only be
used when you truly understand all the ramifications of its use, which
can be extremely hard if not actually impossible to quantify. This
scope by definition renders your build non-portable. It may be
necessarry in certain edge cases. The system scope includes the
element which points to the physical location of this
dependency on the local machine. It is thus used to refer to some
artifact expected to be present on the given local machine an not in a
repository; and whose path may vary machine-to-machine. The systemPath
element can refer to environment variables in its path: ${JAVA_HOME}
for instance.
So, unless you have a solid reason for using this, maybe it's better to deploy the artifact into the repository and reference it like any other artifact?
Related
I am trying to build a Java 11 project with maven and lombok's #Slf4j Logger, but maven does not recognize the log variables. IntelliJ does though and is able to build the project.
The error is
[ERROR]: cannot find symbol variable log
Project and Module SDK is both Java 11. Lombok Version is 1.18.2:
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.12</version>
<scope>provided</scope>
</dependency>
My maven compiler setup:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<source>11</source>
<target>11</target>
<forceJavacCompilerUse>true</forceJavacCompilerUse>
<annotationProcessorPaths>
<path>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.12</version>
</path>
</annotationProcessorPaths>
</configuration>
</plugin>
</plugins>
</build>
I already tried:
turning Annotaion Processing off and on again
reinstalling Lombok plugin
clearing .m2/repository folder
manually adding lombok.jar as Annotation Processor
adding Lombok path to maven-compiler-plugin list of Annotation Processor
This is a really minimal example configuration for using the #Slf4j lombok logging annotation.
You need a logging facade and an implementation, in this case I'm going to use slf4j (as facade) and logback (as implementation).
pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.example</groupId>
<artifactId>untitled</artifactId>
<version>1.0-SNAPSHOT</version>
<properties>
<maven.compiler.source>11</maven.compiler.source>
<maven.compiler.target>11</maven.compiler.target>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.12</version>
<scope>provided</scope>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.30</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.2.3</version>
</dependency>
</dependencies>
</project>
main.java
import lombok.extern.slf4j.Slf4j;
#Slf4j
public class Main {
public static void main(String[] args) {
log.debug("Hello");
}
}
If you get some trouble try always to force the maven dependencies updates running in your project folder mvn -U clean package and reimporting maven project in your IDE
My suspicion is that this is a misleading error message as a consequence of the point that Lombok hooks in during compilation.
In bytecode, there is no concept of an import. Classes are replaced by their fully qualified names (e.g. Integer to java.lang.Integer). Therefore at some point in compilation, the imports are parsed, applied, and any unknown classes (e.g. due to lack of the correct dependency) will throw an error at this stage.
Since #Slf4j means you do not need to import org.slf4j.Logger, the step described above is missed for this class.
After Lombok has appended the log field, the compiler must subsequently look at it's usage, see the class org.slf4j.Logger which it does not recognise and throws an error. Under normal circumstances, due to the earlier compilation stage, the only possible cause is that the field doesn't exist, so infers that the symbol log must be missing. What it is really failing to understand is the type of the field log.
Because Lombok makes changes in the middle of compilation, I guess spurious errors such as these are always a possibility. Perhaps Lombok developers could fix it by doing their own check for org.slf4j.Logger. Most of the functionality provided by Lombok does not involve "importing" external classes, so I'm not surprised that it doesn't handle this edge case as elegantly as possible.
If you add the dependency for SLF4J, the compiler will no longer complain.
In lombok.config file for lombok.log.custom.declaration property use full name including the package for the classes
lombok.log.custom.declaration=com.mycomp.logging.Log
com.mycomp.logging.LogFactory.getLog(TYPE)(TOPIC)
I'm having one of those nights...
I'm developing an Eclipse plugin using Tycho (the Maven extension), and at some point I wanted simply to use the class StringUtils from org.apache.commons. After some research, the only way that I could find is the following code in my pom.xml parent file:
<dependencies>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.3.2</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-maven-plugin</artifactId>
<version>${tycho.version}</version>
<extensions>true</extensions>
</plugin>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<version>${tycho.version}</version>
<configuration>
<pomDependencies>consider</pomDependencies>
<environments>
<environment>
...
This didn't work, and any other solution that I tried didn't work either.
I'm using Maven for the first time, so maybe I'm missing something (or a lot of things)...
Does anyone have an idea? I'd be very thankful :o)
Your configuration looks correct. So if it doesn't work, you are probably missing the dependency declaration in the MANIFEST.MF. To do this, e.g. add Require-Bundle: org.apache.commons.lang3 in that file.
Background: A dependency in the POM doesn't automatically mean for Tycho that your bundle also automatically has this dependency. It only means that the artifact will be added to the target platform (given that pomDependencies=consider is configured and the artifact is an OSGi bundle - both is true in your case). Once it is in the target platform, it can be used to resolve the dependencies declared in your bundle's MANIFEST.MF.
It sounds like you need to "upgrade" to using a target platform to define your target.
How are you achieving this dependency in your development environment? If you are not using a target platform, you are inheriting whatever plug-ins are installed in your development (that is the default target platform).
Create Target Platform
First create a target platform. I recommend using the Target Platform Definition DSL and Generator to create and edit the target platform.
The tpd file will look something like this for orbit
target "name"
with source requirements
location "http://download.eclipse.org/tools/orbit/downloads/drops/R20150519210750/repository/" mars-orbit {
org.apache.commons.lang3
}
location "http://download.eclipse.org/releases/mars" mars-release {
org.eclipse.platform.feature.group
org.eclipse.equinox.executable.feature.group
org.eclipse.e4.rcp.feature.group
org.eclipse.ui.trace
org.eclipse.pde.feature.group
}
This example uses the already created OSGi bundles for third-parties. You can choose which release of orbit and browse all the available packages on the Orbit Site. You can also use auto-completion in the tpd editor.
Tycho Using Target Platform
Place the target file in a new plug-in. Name the target file the same as the plug-in. (e.g. com.example.releng.targetplatform.target is the name of the target file in this example.)
In this project, a pom that looks like this:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<artifactId>com.example.releng.targetplatform</artifactId>
<packaging>eclipse-target-definition</packaging>
<parent>
<groupId>com.example</groupId>
<artifactId>com.example.releng</artifactId>
<version>1.0.0-SNAPSHOT</version>
<relativePath>../com.example.releng</relativePath>
</parent>
</project>
You can configure (in your releng pom.xml) the target configuration like this:
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<version>${tycho-version}</version>
<configuration>
<target>
<artifact>
<groupId>eGui</groupId>
<artifactId>com.example.releng.targetplatform</artifactId>
<version>1.0.0-SNAPSHOT</version>
</artifact>
</target>
</configuration>
</plugin>
Tutorial
Have a look at Code & Me's excellent tutorial on Tycho, it goes into more detail and over many steps goes from new project to a complete Tycho.
I am trying to convert a project from compiling with Java 6 to Java 8. We are using the webstart-maven-plugin for which there is currently a workaround (http://mojo.10943.n7.nabble.com/jira-MWEBSTART-269-Java-8-support-td44357.html) for compiling with Java 8 by adding the following dependencies to the plugin definition.
...
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>webstart-maven-plugin</artifactId>
<version>1.0-beta-6</version>
<dependencies>
<dependency>
<groupId>org.codehaus.mojo</groupId>
<artifactId>webstart-pack200-impl</artifactId>
<version>1.0-beta-6</version>
</dependency>
<dependency>
<groupId>org.codehaus.mojo</groupId>
<artifactId>keytool-api-1.7</artifactId>
<version>1.4</version>
</dependency>
</dependencies>
...
</plugin>
</plugins>
</pluginManagement>
</build>
...
This got me past my initial issues.
I am now receiving the following error.
[ERROR] Failed to execute goal org.codehaus.mojo:webstart-maven-plugin:1.0-beta-6:jnlp-inline (default) on project <redacted>: Unable to parse configuration of mojo org.codehaus.mojo:webstart-maven-plugin:1.0-beta-6:jnlp-inline for parameter pack200: Cannot find default setter in class org.codehaus.mojo.webstart.Pack200Config -> [Help 1]
The Help link goes to the following page.
https://cwiki.apache.org/confluence/display/MAVEN/PluginConfigurationException
As far as I can figure out, the webstart-pack200-impl dependency requires some configuration to define which setter is used. Any information regarding setters that I have found online seems to be a different issue from this. I can't figure out if there is a way to set a configuration for a dependency.
Or am I looking at this in a completely incorrect way?
Many thanks in advance
the error points to pack200 which was configured as <pack200>false</pack200>in older version of webstart plugin configuration.
This can be resolved by changing pack200 configuration to this instead (within <configuration> section of the plugin settings)
<pack200><enabled>false</enabled></pack200>
for more details please refer http://www.mojohaus.org/webstart/webstart-maven-plugin/upgrade.html section "Important changes since 1.0-beta-3"
I just started using Maven and I read that plugins are additional components that can be used.
A typical structure of pom.xml file is
<project>
<groupId>org.koshik.javabrains</groupId>
<artifactId>JarName</artifactId> (A fldernamed JarName was created)
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<name>JarName</name>
<url>http://maven.apache.org</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
Question: Where should I insert a plugin tag? such as the following:
<plugin>
<groupId>org.jibx</groupId>
<artifactId>jibx-maven-plugin</artifactId>
<version>1.2.4</version>
<executions>
<execution>
<goals>
<goal>bind</goal>
</goals>
</execution>
</executions>
</plugin>
Before the dependency or after the dependency tag? Does it matter?
<project>
<groupId>org.koshik.javabrains</groupId>
<artifactId>JarName</artifactId> (A fldernamed JarName was created)
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<name>JarName</name>
<url>http://maven.apache.org</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.jibx</groupId>
<artifactId>jibx-maven-plugin</artifactId>
<version>1.2.4</version>
<executions>
<execution>
<goals>
<goal>bind</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
You can also place plugins in the <build> section of <profile> if you use maven profiles. The order doesn't matter.
A late clarification on two important points
Where to place plugin
A plugin should indeed be added in most of the cases within the build/plugins section, however there is an important difference between placing it within plugins against placing it within pluginManagement/plugins.
This misunderstanding is often the cause of a non invoked plugin in Maven or an harder troubleshooting:
Plugins under build/plugins are directly part of the default Maven build, if they specify an execution or if they configure something for the default build (see below)
Plugins under build/pluginManagement/plugins are not necessarely part of the default Maven build, that is, is a management, it's an hint to maven: it you happen to use this plugin, then please use the version, the configuration, the executions I specify here, in this management.
But what happen to use means? Means: if the same plugin is also present in the build/plugins section, then apply this management (and only then it will be effective); or if the plugin is invoked by default by Maven, then also apply it.
But how is a plugin invoked by default? That's part of the main philosophy behind maven: convention over configuration. By convention, when you specify a certain packaging (default jar, but it can be war for example), you want certain plugins to be invoked. To build a jar, by default invoke the maven-jar-plugin; to build a war, by default invoke the maven-war-plugin and so on. So, if you specify a plugin configuration in the build/pluginManagement/plugin for a plugin which has a default binding to the Maven build, then it will be also be used.
Ordering
Concerning the ordering of sections within the pom.xml file, a further clarification is required: it's indeed irrelevant in most of the cases, however the order of plugin element wihtin the build/plugins section may be important. Since Maven 3.0.3 (MNG-2258), different plugin executions attached to the same Maven phase will be invoked in their order of declaration in the pom.xml file. That is, ordering is important in this case, since it may affect the behavior of the build.
Additionally, also order of dependency declarations may affect your build towards Dependency Mediation, that is, the first declared dependency wins in case of conflict against a transitive dependency. So, once again, ordering is important in certain cases.
Last but not least, although ordering is not important for other sections of the pom.xml file, good habit is to follow official Maven recommendations and, as a simplified version, follow this order of declaration:
<project>
<modelVersion/>
<parent/>
<groupId/>
<artifactId/>
<version/>
<packaging/>
<properties/>
<dependencyManagement/>
<dependencies/>
<build/>
<reporting/>
<profiles/>
</project>
The sortpom-maven-plugin can also be used to automatically apply this standard ordering, simply invoking the following on the concerned pom.xml file:
mvn com.github.ekryd.sortpom:sortpom-maven-plugin:2.5.0:sort \
-Dsort.keepBlankLines -Dsort.predefinedSortOrder=recommended_2008_06
For further reading:
Stack Overflow: Maven: what is pluginManagement?
Official Maven doc: Maven POM Reference, PluginManagement
Official Maven default bindings
Official Maven doc: Dependency Mediation
Official Maven doc: Maven Code Style And Code Conventions
<plugin>should be placed into <plugins> section which should be placed into <build> or <pluginManagement> section.
The order of <dependency> or <build> section doesn't matter.
The full reference about pom.xml is here: http://maven.apache.org/pom.html
If you want to use the plugin for build you can use the below structure.
<project>
<build>
<plugins>
</plugins>
</build>
</project>
You can insert your second snippet anywhere in the pom.xml file between two <plugins> </plugins> tags.
Sections order in POM doesn't matter. In general, there are build plugins and reporting plugins in Maven. Your case is to use build plugin so you have to put this <plugin> block into <project><build><plugins>... section.
Look at this for some basics about plugins.
As additional answer for Reporting Plugins (e.g. maven-checkstyle-plugin) there are 2 tags under which plugins can go in pom.xml, under build and reporting.
Using the reporting Tag VS build Tag
Configuring a reporting plugin in the or elements
in the pom does NOT have the same behavior!
mvn site
It uses only the parameters defined in the
element of each reporting Plugin specified in the element,
i.e. site always ignores the parameters defined in the
element of each plugin specified in .
mvn aplugin:areportgoal
It uses firstly the parameters defined in the element
of each reporting Plugin specified in the element; if a
parameter is not found, it will look up to a parameter defined in the
element of each plugin specified in .
Source: https://maven.apache.org/guides/mini/guide-configuring-plugins.html#Using_the_reporting_Tag_VS_build_Tag
I often encounter distributions of Java applications or libraries which
use Maven as their build tool.
Some of them, sadly, don't provide standalone (or redistributable) jars.
Is it possible to build Maven-based applications in such a way, that
the build result contains all dependencies and can be redistributed to work out-of-the box?
I tried to build Jackrabbit's OCM module.
For some very "intelligent" reasons there is no downloadable standalone
version.
So I built Jackrabbit with Maven (the source package of Jackrabbit includes
OCM), and got the same jar as found in the apache repository.
The jar doesn't contain necessary dependencies and is useless to me.
As Dominic said, using the assembly plugin will do the trick. You would usually configure it inside your own project's POM to gather and package all required dependencies:
...
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
</plugin>
...
jar-with-dependencies is predefined by the assembly plugin and will include all dependencies in the final package (see the documentation here).
If you don't want to use Maven for your own project, you will need to modify the libraries' POMs and repackage them yourself (download the sources, add the above snippet to pom.xml and run mvn package). Beware of duplicate or incompatible transitive dependencies if you use multiple libraries. exclusions might help in that case (see documentation here).
Use the Maven Shade plugin
...but be careful of the gotchas (similar to the one described further down my answer), which has got a workaround explained here.
Also, be ultra careful with the Shade plugin config. I accidentally used double <configuration> tags once, and the transformers didn't apply at all, and the plugin also took the liberty of not warning me.
Don't use the Maven Assembly plugin
assembly:single will unpack your dependency JARs as-is, and this could not be what you want. E.g. stuff like META-INF/spring.schemas will be overridden with the last Spring dependency JAR that's evaluated, and as such your XSDs won't be found (apart from those in the last JAR, of course). Which is why systems like Alfresco made their AMP plugin which bundles dependencies inside lib/ inside the AMP you're building. The latter raises dependency management issues, though.
You may have some luck with the appassembler plugin. Failing that, take a look at the assembly plugin. That's more flexible, but lower level. If you're using the assembly plugin, you may find the chapter on it in maven: the definitive guide to be useful.
As a couple of the posters said, the assembly plugin is a good way of creating a complete jar file, with all project dependencies. However, you don't actually have to modify the pom.xml file. Simply run:
mvn assembly:single -DdescriptorId=jar-with-dependencies
... in order to create a jar file. If you want to do anything more advanced, you should probably modify pom.xml, and create a custom assembly descriptor.
Change the pom.xml file and use the <Embed-Dependency> directive. A similar example can be found here so you can adapt it to your scenario.
<Embed-Dependency>*;scope=!test;inline=true</Embed-Dependency>
I think this should do the trick.
Here is the example at the above URL that seems to give timeout.
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>br.gov.lexml</groupId>
<artifactId>toolkit</artifactId>
<packaging>bundle</packaging>
<version>3.0</version>
<parent>
<artifactId>lexml</artifactId>
<groupId>br.gov.lexml</groupId>
<version>1.0</version>
</parent>
<build>
<finalName>Lexml_Toolkit-2.0</finalName>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<!--_include>src/toolkit/resources/META-INF/MANIFEST.MF</_include-->
<Export-Package>*;-split-package:=merge-last</Export-Package>
<Bundle-Activator>br.gov.lexml.borda.Toolkit</Bundle-Activator>
<Bundle-Name>Toolkit</Bundle-Name>
<Private-Package />
<Embed-Dependency>*;scope=!test;inline=true</Embed-Dependency>
<Bundle-ClassPath>.,{maven-dependencies}</Bundle-ClassPath>
</instructions>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>org.apache.xmlbeans</groupId>
<artifactId>xmlbeans</artifactId>
<version>2.4.0</version>
</dependency>
<dependency>
<groupId>org.apache.xmlbeans</groupId>
<artifactId>xmlbeans-xmlpublic</artifactId>
<version>2.4.0</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.15</version>
</dependency>
<dependency>
<groupId>br.gov.lexmlbeans</groupId>
<artifactId>lexmlbeans</artifactId>
<version>3.0</version>
</dependency>
</dependencies>
</project>
I believe the Maven Shade Plugin will satisfy your needs. I use it when I am building command line interface tools to create an Uber JAR including my classes and along with the classes from all my dependencies.
Its very easy to use and I think this example is self-explanatory.