I have a dependency in my POM that needs to be set to "provided" so it is not included at compilation, but it can still be referenced within my project. I would like the same dependency to have a scope of "test" when I go to run tests so I do not have to manually add the jar to my classpath. Is there a way to do this or achieve similar results?
Reasoning behind this is that I have some common jars that are provided in my JBOSS lib directory, so I want to use these and keep the "provided" scope of them for the war that is built. However, when I run JUnits from the command line, I want to use the jar from the repository without manually adding it to my classpath.
Thanks in Advance
From maven documentation:
provided This is much like compile, but indicates you expect the JDK
or a container to provide the dependency at runtime. For example, when
building a web application for the Java Enterprise Edition, you would
set the dependency on the Servlet API and related Java EE APIs to
scope provided because the web container provides those classes. This
scope is only available on the compilation and test classpath, and is
not transitive.
I checked this works for me in maven 3.0.3. Had the same issue that i needed to have a servlet dependency while compilation and test but not compiled in because it ships with the application server distribution.
You could use a profile that either declares those dependencies as test or as provided - depending on what is more convenient for you:
<profiles>
<profile>
<id>whatever</id>
<activation>
<property>
<name>env</name>
<value>whatever</value>
</property>
</activation>
<dependencies>
<dependency>
<groupId>yours</groupId>
<artifactId>yours</artifactId>
<scope>provided</scope>
</dependency>
</dependencies>
</profile>
<profile>
<id>test</id>
<activation>
<property>
<name>env</name>
<value>test</value>
</property>
</activation>
<dependencies>
<dependency>
<groupId>yours</groupId>
<artifactId>yours</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
</profile>
</profiles>
Those profiles get activated by setting the property env but there are other ways, f.e. default activation - have a look here for that.
Try declaring the dependency twice, once with each scope. Works in Maven 2.2.1.
Confusing things happen with dependency resolution, when the same artifact is in the dependency tree twice with different scopes, but I don't think it should be a problem in your case.
Have the same issue, reason why i need two scopes for the same dependency is on phase integrating test i use jetty-plugin for run rest service, and make some JUnit testing while jetty is running, but i compile my package for jboss as, where i already have "resteasy-cdi", than absent for jetty servlet container...I have no found solution yet.
Use the maven-surefire-plugin to run your junit tests. The scope of provided will also make it available on the test classpath.
Please find the exact meaning of scopes in Maven
I refered to Maven http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
Dependency scope is used to limit the transitivity of a dependency, and also to affect the classpath used for various build tasks.
There are 6 scopes available:
compile:-
This is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects.
provided:-
This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.
runtime:-
This scope indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath.
test:-
This scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases.
system:-
This scope is similar to provided except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository. import (only available in Maven 2.0.9 or later):- This scope is only used on a dependency of type pom in the section. It indicates that the specified POM should be replaced with the dependencies in that POM's section. Since they are replaced, dependencies with a scope of import do not actually participate in limiting the transitivity of a dependency.
Related
I just finished converting one of our in-house framework projects from ant to maven. The maven build runs fine, and deploys to our repository with no issues.
The problem is when other projects try to consume the framework, it does not work. The only thing downloaded is top level framework pom.
I have tried adding some dependency entries to one or more of the various modules, but no matter which one I add, I get a circular dependency error. I also tried creating a 2nd top level pom file with no modules and a few dependencies to overwrite the one in the repository manager. This causes some of the dependencies to be downloaded, but then the maven build will hang in random places. based on windows task manager, it looks like its in an endless loop. So a 2nd pom file does not appear to be the answer (or im doing it wrong).
my framework pom file looks something like this:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>framework_snt</groupId>
<artifactId>SFP</artifactId>
<packaging>pom</packaging>
<name>SFP framework</name>
<version>6.3</version>
<modules>
.... 50+ modules here
</modules>
and then the usual properties, dependency management and pluginManagement entries for a top level pom.
in the consuming module I just have the following:
<dependency>
<groupId>framework_snt</groupId>
<artifactId>SFP</artifactId>
<version>6.3</version>
<type>pom</type>
</dependency>
This is in the top level pom so all submodules have access to the framework libraries to make it easier on the developers.
How do I set things up so so all the dependent jar files will be downloaded by my consuming projects ?
It sounds like your framework project produces several jar artifacts, one for each child module, but no jar artifact for the parent project. Thus, declaring a dependency on the parent project's pom is not what you want to do. Instead you need to declare a dependency on each of your framework project's child modules.
I have a similar setup where I have a "toolkit" project with several modules (each producing a jar artifact). Then in my other projects I declare dependencies on whatever modules I need to use. I do not, however, declare a dependency on my "toolkit" parent projects pom file. Instead I just declare dependencies on the child modules jar artifacts.
<dependency>
<groupId>com.mycompany.toolkits</groupId>
<artifactId>file-utils</artifactId>
<version>1.0.0</version>
</dependency>
Notice that my dependency declaration points to one of my child module's and does not declare <type>pom</type> like you did. If you wanted to be really explicit you could declare <type>jar</type> instead.
The framework pom as you call it is the parent pom of your multi-module project.
While the modules can depend on each other, it cannot depend on this parent pom. This is what is possibly causing the circular dependency.
You will need to relook at your modules and identify which modules depend on which and suitably specify the dependencies. Also, these dependencies are typically jar dependencies - a packaging which will contain sources and resources.
Maven By Example is one of the many resources available which gives further information.
We have a mother-ship project with several modules:
foo
+ foo-core
+ foo-resource
+ foo-util
+ foo-whatever
I want to allow developers to include the core, resource, and util modules as dependencies (excluding the -whatever module). I know that I can specify that they include each dependency, but it would be nice to allow for them to just specify something like
<artifactId>foo-sdk</artifactId>
And get everything that they need to develop a foo. This has the added advantage that it gives us the power to add (or remove) what goes into the sdk.
It would be best if foo-sdk was not just a jar with the other jars jammed in it. I'd rather it be a pom that simply points to the other artifacts.
I feel like I've seen this done before but can't find instructions to do it. I checked out Maven Assembly Plugin but it doesn't look like this is its intended use.
You can group dependencies in a project with a packaging of type pom. From the Maven book:
3.6.1. Grouping Dependencies
If you have a set of dependencies
which are logically grouped together.
You can create a project with pom
packaging that groups dependencies
together. For example, let's assume
that your application uses Hibernate,
a popular Object-Relational mapping
framework. Every project which uses
Hibernate might also have a dependency
on the Spring Framework and a MySQL
JDBC driver. Instead of having to
include these dependencies in every
project that uses Hibernate, Spring,
and MySQL you could create a special
POM that does nothing more than
declare a set of common dependencies.
You could create a project called
persistence-deps (short for
Persistence Dependencies), and have
every project that needs to do
persistence depend on this convenience
project:
Example 3.11. Consolidating Dependencies in a Single POM Project
<project>
<groupId>org.sonatype.mavenbook</groupId>
<artifactId>persistence-deps</artifactId>
<version>1.0</version>
<packaging>pom</packaging>
<dependencies>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate</artifactId>
<version>${hibernateVersion}</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-annotations</artifactId>
<version>${hibernateAnnotationsVersion}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-hibernate3</artifactId>
<version>${springVersion}</version>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>${mysqlVersion}</version>
</dependency>
</dependencies>
<properties>
<mysqlVersion>(5.1,)</mysqlVersion>
<springVersion>(2.0.6,)</springVersion>
<hibernateVersion>3.2.5.ga</hibernateVersion>
<hibernateAnnotationsVersion>3.3.0.ga</hibernateAnnotationsVersion>
</properties>
</project>
If you create this project in a
directory named persistence-deps, all
you need to do is create this
pom.xml and run mvn install. Since
the packaging type is pom, this POM
is installed in your local repository.
You can now add this project as a
dependency and all of its dependencies
will be added as transitive
dependencies to your project. When you
declare a dependency on this
persistence-deps project, don't
forget to specify the dependency type
as pom.
Example 3.12. Declaring a Dependency on a POM
<project>
<description>This is a project requiring JDBC</description>
...
<dependencies>
...
<dependency>
<groupId>org.sonatype.mavenbook</groupId>
<artifactId>persistence-deps</artifactId>
<version>1.0</version>
<type>pom</type>
</dependency>
</dependencies>
</project>
If you later decide to switch to a
different JDBC driver (for example,
JTDS), just replace the dependencies
in the persistence-deps project to use
net.sourceforge.jtds:jtds instead of
mysql:mysql-java-connector and update
the version number. All projects
depending on persistence-deps will use
JTDS if they decide to update to the
newer version. Consolidating related
dependencies is a good way to cut down
on the length of pom.xml files that
start having to depend on a large
number of dependencies. If you need to
share a large number of dependencies
between projects, you could also just
establish parent-child relationships
between projects and refactor all
common dependencies to the parent
project, but the disadvantage of the
parent-child approach is that a
project can have only one parent.
Sometimes it makes more sense to group
similar dependencies together and
reference a pom dependency. This way,
your project can reference as many of
these consolidated dependency POMs as
it needs. Note
Maven uses the depth of a dependency
in the tree when resolving conflicts
using a nearest-wins approach. Using
the dependency grouping technique
above pushes those dependencies one
level down in the tree. Keep this in
mind when choosing between grouping in
a pom or using dependencyManagement
in a parent POM
Wouldn't this just be another sub-module foo-sdk with packaging pom and dependencies on foo-{core,resource,util}?
My company writes companion products for project management software that uses that software's Java API. They release new API versions with new releases of their products, and also point releases for bug fixes etc. We need to support clients using various versions of their software (and by extension, their API). In order to do this without unnecessary code duplication, we have defined profiles in our products that include the necessary dependencies for each API version.
I have a war project built using this technique with the "api70" profile activated, and another project that depends on that war project with a type of pom, in order to pull in the war's dependencies. The problem is that when building this second project, the profile-specific dependencies are not being included, even though I'm defining -Papi70 on the maven command line when building the depending project.
Is there any way to get this to work?
In the war project:
<!-- API 7.0 profile. -->
<profile>
<id>api70</id>
<dependencies>
<dependency>
<groupId>com.bigcompany</groupId>
<artifactId>integrationlibrary</artifactId>
<version>7.0-a</version>
</dependency>
</dependencies>
<properties>
<apiversion>api70</apiversion>
</properties>
</profile>
In the depending project:
<!-- Depend on war as type=pom for dependency mediation. -->
<dependency>
<groupId>com.mycompany</groupId>
<artifactId>warproject</artifactId>
<version>${warVersion}</version>
<type>pom</type>
</dependency>
Command line used for building depending project:
mvn -P api70 clean package
The resulting build does not include integrationlibrary or any of its transitive dependencies.
I think that your problem doesn't apply to profiles at all. It's about how transitive dependencies work for war packaging. By design they doesn't work :) War archive contain its dependencies in WEB-INF/lib folder or if it is packaged in ear it can share libraries with ear libs. More of the problem you can read on this wiki article. It's about Skinny Wars but topic relates also your problem.
For you interesting is also this JIRA issue.
Quick but not elegant solution is to change packaging form war to pom (or create duplicate pom with pom packaging).
Why don't you create an api70-deps pom project and let your war and dependant project both pull that in, profile activated or otherwise?
This approach works wonders for me... my poms become so much more tidier.
I use maven/hudson to build my project. One of the goals run by hudson is mvn package so I have a full distribution produced on every build. Is there a way (maybe an argument to package?) that I can append the build number to the name of archive that's produced?
thanks,
Jeff
Try the following. It should only activate if the BUILD_NUMBER property is set, so you'll still generate correctly named builds when not using hudson.
<profiles>
<profile>
<id>hudson-build</id>
<activation>
<property>
<name>BUILD_NUMBER</name>
</property>
</activation>
<build>
<finalName>${artifactId}-${version}-${BUILD_NUMBER}</finalName>
</build>
</profile>
</profiles>
I'd suggest putting this into a base pom.xml that can then be referenced as a parent to your other pom.xml configs.
For a list of other properties that hudson passes on to maven builds, see http://weblogs.java.net/blog/johnsmart/archive/2008/03/using_hudson_en.html.
You can pass an arbitrary property to a Maven build using -D[key]=[value], for example -DbuildNumber=1234 then configure the version in your pom as `1.0.0-${buildNumber}. This approach goes against the general Maven principle though. You'd be better to use Maven's SNAPSHOT processing. SNAPSHOT is a keyword to Maven to update the dependency each time.
You could also use the buildnumber-maven-plugin to automatically add a number to the build version each time. See this answer for some details. The buildnumber plugin can be set to produce a revision based on the SCM revision, a timestamp, or on a sequence.
Does anyone know of a way to set a specific classpath order in Maven2, rather than the random ordering I appear to experience at the moment?
There are a number of legitimate reasons for wanting to do this:
A vendor has supplied a patch jar, which contains overriding classes for a previously released jar and therefore the patch jar must appear first in the classpath ordering.
Two jar's found on the classpath discovered by traversing pom dependencies contain the same class in the same package with different signitures. For example:
jboss
jbossall-client
4.2.0.GA
org.hibernate
hibernate
3.1
both contain:
org.hibernate.util.ReflectHelper.class, but the jbossall-client version is missing the getFastClass method.
From googling I see that this is perhaps a point of contention between maven enthusiasts and people facing this particular issue, but surely there are legitimate reasons for classpath ordering.
Any advice from anyone that has solved this particular quandary would be much appreciated!
Thanks
As of version 2.0.9 maven uses pom order for classpath, so you can actually manipulate it now. We mostly supress transitive dependencies to external libraries that we also include directly.
From the release notes of maven 2.0.9:
MNG-1412 / MNG-3111 introduced deterministic ordering of dependencies on the classpath. In the past, natural set ordering was used and this lead to odd results. The ordering is now preserved from your pom, with dependencies added by inheritence added last. In builds that had conflicting or duplicate dependencies, this may introduce a change to the output. In short, if you have weird issues with 2.0.9, take a look at the dependencies to see if you have conflicts somewhere.
Maven 2.0.9 adds correct ordering so you absolutely must have that version or higher for the below to work.
Secondly you need the an updated plugin. The Maven guys are working on a fix, its in their jira to fix but this is something I urgently needed. So in the meantime I have fixed this myself and you can pull the Modified plugin source code from github.
Edit: Refer to http://jira.codehaus.org/browse/MECLIPSE-388
There are two ways to install it, either pull my modified code and install it or download the prebuilt jar and just add it.
Building the plugin
Run maven install from the plugin directory you checked out and then add the following in your plugins section of your projects pom:
<build>
</plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-eclipse-plugin</artifactId>
<version>2.8-cpfix</version>
</plugin>
</plugins>
</build>
Download the jar
Alternatively if you don't want to download and compile yourself then you can just get hold of the jar file and install it yourself.
Once you have the file run
mvn install:install-file -Dfile=<path-to-file> -DgroupId=org.apache.maven.plugins \
-DartifactId=maven-eclipse-plugin -Dversion=2.8-cpfix -Dpackaging=jar
Regardless of how you installed it now when you run mvn eclipse:eclipse it will pick up the modified code and order the dependencies based on the order you defined in your pom file, no alphabetical ordering. It will also put the JRE container at the top of the dependencies.
Hopefully the real version of this code will come out soon, but in the meantime this fix has worked for me on my project and I hope it can help some others as well.
Rather a further qualification of the question than an answer:
under "Maven Dependencies" Eclipse does not seem to honour the POM-order.
(it does use the POM-order under "Java Build Path" & in the Classpath)
Is that the expected behaviour?
I'm using Eclipse 2021-09 (which has Maven 3.8.1 embedded) under Windows 10.
Here's the POM:
<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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.group</groupId>
<artifactId>arty.fact</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>Maven Dependency Order</name>
<properties>
<maven.compiler.target>17</maven.compiler.target>
<maven.compiler.source>17</maven.compiler.source>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>wsdl4j</groupId>
<artifactId>wsdl4j</artifactId>
<version>1.6.3</version>
<exclusions><exclusion><groupId>*</groupId><artifactId>*</artifactId></exclusion></exclusions>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.14.1</version>
<exclusions><exclusion><groupId>*</groupId><artifactId>*</artifactId></exclusion></exclusions>
</dependency>
</dependencies>
</project>
The Maven Dependencies looks like this:
If you have problem starting with IntelliJ IDEA, you can change the dependencies order from project structrue.