how to exclude a dependency from war but using it till testing or development
As the others suggested, scope=provided or scope=test is the way to go.
<scope>provided</scope> implies that the library will be present in the target system and doesn't need to be deployed. (Or in some cases like log4j must not be deployed, because otherwise classloader issues will result)
<scope>test</scope> suggests that the dependency is only needed for test code (and hence will not be needed or provided on the target system)
Here is the relevant documentation:
Introduction to the Dependency Mechanism
On a related note: A different use case is that where you use different databases on different servers. You can use profiles to deploy the correct drivers:
<profiles>
<profile>
<id>testserver</id>
<dependencies>
<dependency>
... (database driver a)
</dependency>
</dependencies>
</profile>
<profile>
<id>productionserver</id>
<dependencies>
<dependency>
... (database driver b)
</dependency>
</dependencies>
</profile>
<profile>
<id>localdevelopment</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<dependencies>
<dependency>
... (database driver c)
</dependency>
</dependencies>
</profile>
</profiles>
That way, if you just call mvn install, driver c will be deployed, whereas mvn install -Ptestserver and mvn install -Pproductionserver will include drivers a or b, respectively.
There is an option to specify scope with in the dependency tag. You can specify scope as test and it won't be included into your war but will only be used for tests.
You do it with <scope>provided</scope> tag.
<dependency>
<groupId>org.livetribe</groupId>
<artifactId>livetribe-jsr223</artifactId>
<version>2.0.6</version>
<scope>provided</scope>
</dependency>
Related
I have a multi-module project, and I am using profiles in the parent pom , which have specific dependencies mentioned in them.
The issue here is that, if in a child pom , I am overriding the dependency element, and mentioning one of the dependencies in the parent pom (which is declared in a profile in parent pom) , the version of that specific dependency needs to be mentioned again.
E.g
Parent pom
<dependencies>
<dependency>
<groupId>com.mycode.apps</groupId>
<artifactId>jobs</artifactId>
<version>4</version>
</dependency>
</dependencies>
<profiles>
<profile>
<id>common-dependencies</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<dependencies>
<dependency>
<groupId>com.mycode.apps</groupId>
<artifactId>dao</artifactId>
<version>4</version>
</dependency>
</dependencies>
</profile>
</profiles>
Now in child pom.xml
<dependencies>
<!--this one doesnt need a version specified -->
<dependency>
<groupId>com.mycode.apps</groupId>
<artifactId>jobs</artifactId>
</dependency>
<!--this one makes maven throw an error(if version is not specified) while compilation -->
<dependency>
<groupId>com.mycode.apps</groupId>
<artifactId>dao</artifactId>
</dependency>
</dependencies>
Any idea what might be wrong and how can I fix this??
NOTE: The profile is marked as activeByDefault
For this kind of requirments you the dependencyManagement which is exactly for such cases. Or take look into the Sonatype Book.
This case shouldn't be handled by profiles.
We need to build project with different versions of deps (in this example, Postgres 8 and Postgres 9). Also, our developers have different versions of DBs on their computers.
I'm tried to do something like this:
<profile>
<id>postgres9</id>
<properties>
<postgres.driver.version>
9.0-801
</postgres.driver.version>
</properties>
</profile>
<profile>
<id>postgres8</id>
<properties>
<postgres.driver.version>
8.3-603
</postgres.driver.version>
</properties>
</profile>
<dependency>
<groupId>postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>${postgres.driver.version}</version>
</dependency>
<properties>
<postgres.driver.version>8.3-603</postgres.driver.version>
</properties>
mvn clean test -Ppostgres9
But it didn't work. Profile variable is not overriding pom variable at all. Also, I cannot achieve that even with the ~/.m2/settings.xml.
Does anyone know how to do this? Thanks.
We've been trying to do similar things in our projects for quite a while. The only way that consistently works is to pass -Dpostgres.driver.version=8.3-603. For some reason, variables are not interpolated before dependencies are computed.
Oddly enough, it seems to work on some of my projects under Maven 3.0.2. I'm trying to investigate deeper now.
I had the same problem.
Moving the version (with the property) from dependency to dependencyManagement in the parent pom solved it for me:
old:
pom.xml:
<dependencies>
<dependency>
<groupId>postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>${postgres.driver.version}</version>
</dependency>
</dependencies>
new:
pom.xml
<dependency>
<groupId>postgresql</groupId>
<artifactId>postgresql</artifactId>
</dependency>
parent pom:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>${postgres.driver.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
I work with Maven and I want to do a build with packaging ear, i want to add a dependency with scope system and also with specifing the systemPath of the jar like follow:
<dependency>
<groupId>group1</groupId>
<artifactId>group1</artifactId>
<version>1</version>
<scope>system</scope>
<systemPath>D:\Buildear\Jars\file.jar</systemPath>
</dependency>
But I don't found the jar in my generater ear!!!
Help please.
I work with Maven and I want to do a build with packaging ear, I want to add a dependency with scope system (...). But I don't found the jar in my generater ear!!!
Yes, that's just what you get when (ab)using a system scoped dependency which is supposed to be always available by definition. I wrote many times about this, for example in this previous answer that I'm quoting below:
I already wrote many, many,
really many times about this
here on SO and in 99% of the cases,
system scoped dependencies should be
avoided. And I'll repeat what the
Dependency Scopes mini guide says
one more time:
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
necessary in certain edge cases. The
system scope includes the
<systemPath> 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, instead of using the system
scope, either:
Add your libraries to your local repository via install:install-file.
This is a quick and dirty way to get
things working, it might be an option
if you're alone but it makes your
build non portable.
Install and run an "enterprise repository" like Nexus, Archiva, or
Artifactory and add your libraries via
deploy:deploy-file. This is the
ideal scenario.
Setup a file based repository as described in this previous answer
and put your libraries in there. This
is the best compromise if you
don't have a corporate repository but
need to work as a team and don't want
to sacrifice portability.
Please, stop using the system scope.
<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>
<parent>
<artifactId>aaa</artifactId>
<groupId>aaa</groupId>
<version>1.0</version>
</parent>
<groupId>aaa</groupId>
<artifactId>aaa</artifactId>
<version></version>
<packaging>ear</packaging>
<name>aaa - Ear</name>
<dependencies>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>aaa-ejb</artifactId>
<version>${project.version}</version>
<type>ejb</type>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>aaa-webapp</artifactId>
<version>${project.version}</version>
<type>war</type>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>jboss</groupId>
<artifactId>jboss-common</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>jboss</groupId>
<artifactId>jbosssx</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.transaction</groupId>
<artifactId>jta</artifactId>
<version>1.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<scope>provided</scope>
</dependency>
</dependencies>
<build>
<finalName>${aaa.name}-${project.version}</finalName>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<generateApplicationXml>false</generateApplicationXml>
<defaultLibBundleDir>lib</defaultLibBundleDir>
<modules>
<ejbModule>
<groupId>${project.groupId}</groupId>
<artifactId>aaa-ejb</artifactId>
</ejbModule>
<jarModule>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
<excluded>true</excluded>
</jarModule>
</modules>
</configuration>
</plugin>
</plugins>
</build>
<properties>
<aaa.name>aaa-batch</aaa.name>
</properties>
This creates an ear and copies the libraries into the lib folder in the ear.
I have a maven module which has some dependencies. In a certain profile, I want to exclude some of those dependencies (to be exact, all dependencies with a certain group id). They however need to be present in all other profiles. Is there a way to specify exclusions from the dependencies for a profile?
To my knowledge, no, you can't deactivate dependencies (you can exclude transitive dependencies but this is not what you are asking for) and yes, what you are currently doing with the POM (manually editing it) is wrong.
So, instead of removing dependencies, you should put them in a profile and either:
Option #1: use the profile when required or
Option #2: mark the profile as activated by default or put it in the list of active profiles and deactivate it when required.
A third option would be (not profile based):
Option #3: separate things in two separated modules (as you have separated concerns) and use inheritance.
Instead of excluding dependencies in a profile, you can set them as provided in it. This doesn't require any overly complex configuration and will exclude the dependencies you don't want from the final build.
In the desired profile, add a dependencies section, copy the declaration of the ones you want to exclude and scope them as provided.
For example, let say you want to exclude slf4j-log4j12:
<profiles>
<!-- Other profiles -->
<profile>
<id>no-slf4j-log4j12</id>
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.2</version>
<scope>provided</scope>
</dependency>
</dependencies>
</profile>
<!-- Other profiles -->
</profiles>
One way that occurs to me is to have the dependencies in a separate pom. You can then add an <exclusions> section via the profile.
<dependencies>
<dependency>
<groupId>my.company.dependencies</groupId>
<artifactId>my-dependencies</artifactId>
<version>1.0.0-SNAPSHOT</version>
<type>pom</type>
</dependency>
</dependencies>
<profile>
<activation>
<activeByDefault>false</activeByDefault>
<property>
<name>exclude-deps</name>
</property>
</activation>
<dependencies>
<dependency>
<groupId>my.company.dependencies</groupId>
<artifactId>my-dependencies</artifactId>
<version>1.0.0-SNAPSHOT</version>
<type>pom</type>
<exclusions>
<exclusion>
<groupId>my.company</groupId>
<artifactId>bad-dep-1</artifactId>
</exclusion>
<exclusion>
<groupId>my.company</groupId>
<artifactId>bad-dep-2</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
</profile>
I don't think it is possible to exclude direct dependencies either (at least, nothing is mentioned here).
The best thing you can do is to enclose the desired dependencies for each case into different profiles (as suggested already), but, you'll need to create two "mutually exclusive" profiles with the one of them "active by default". The most reliable way to achieve this is by using a parameter for your profile activation e.g.
<profiles>
<profile>
<id>default-profile</id>
<activation>
<property><name>!exclude</name></property>
</activation>
<dependencies>
dependency-A
dependency-B
...
</dependencies>
</profile>
<profile>
<id>exclude-profile</id>
<activation>
<property><name>exclude</name></property>
</activation>
<!-- exclude/replace dependencies here -->
</profile>
</profiles>
Then using "mvn [goal]" will use profile "default-profile", but "mvn [goal] -Dexclude" will use profile "exclude-profile".
Note that using 'activeByDefault' instead of a parameter for your "default" profile might work in some cases but it also might lead to unexpected behavior. The problem is that 'activeByDefault' makes a profile active as long as there is no other active profile in any other module of a multi-module build.
maven is a tool, we can hack it.
maven runs fine if you have the same artifact + version defined as dependency twice.
define a profile that eliminates an artifact + version by changing it to another package we already have.
For example, in the pom.xml:
... other pom stuff ...
<properties>
<artifact1>artifact1</artifact1>
<artifact2>artifact2</artifact2>
<artifact1.version>0.4</artifact1.version>
<artifact2.version>0.5</artifact2.version>
</properties>
<profile>
<id>remove-artifact2</id>
<properties>
<artifact1>artifact1</artifact1>
<artifact2>artifact1</artifact2>
<artifact1.version>0.4</artifact1.version>
<artifact2.version>0.4</artifact2.version>
</properties>
</profile>
Now if you install this pom.xml without the profile, artifact1:0.4 and artifact2:0.5 will be the dependency.
But if you install this pom.xml with the profile mvn -P remove-artifact2
The result pom.xml contains only artifact1:0.4
This comes quite handy during api migration where artifact are renamed and versions are not compatible.
Bit dirty but lightweight solution is to use <scope>import</scope>.
Unlike the other scopes you could use this:
will disable compile-time and runtime dependecies; unlike provided or runtime which disables only one at a time
won't mess up your test scope
you don't need to specify path to some dummy jar as would system scope require
Nothing gets imported as long as you use this hack outside dependencyManagement.
What is the best way to split up a large enterprise project in Maven?
It's easy enough to understand how to partition things vertically like this...
You have a DAO project
The DAO project is a dependency of
the Service project
The Service project is a dependency
of the web project.
Does anybody have input on best practices in partitioning/splitting up really large projects in Maven.m
Some things that have helped me
Use multi-module projects for projects that are related and only projects that are related. An EJB that exists only in a single EAR is a candidate for this. A bo layer that is used by an EJB and a client app is not.
One Artifact per pom, one deployable per multi-module project Do Not Waste Time trying to get around this.
Create dependency poms that include common sets of dependencies. That way you can include your DAO, your jdbc driver and your ORM tools with a single dependency. It also makes upgrading dozens of projects to the newest version of your ORM or DAO that much easier.
Create builder projects that exist only to run assembly and create deployment sets. This will keep multiple parts of your project in sync. Assembling large complex enterprise apps is often complicated enough that you need a mix of maven, shell scripts and/or ant:run tasks plus dozens of profiles. Putting the mess in a project far away from your code will contain the mess before it spreads.
Create tester projects for continuous integration use. Define your web and app servers in those poms as well as the test deployment info. Use of parent projects and common properties files will make testing deployment changes easier.
Define distributionManagement in a parent pom only if it is possible to make all sub-projects a child (or grand-child) of it.
Try not to depend on large files (EAR, WAR) being stuffed into your repository on every build. Removing the need for a 175mb WAR to be pushed to nexus on each snapshot improved our build times.
Try to define things as few times as possible. A DRY build is a happy build. Having 30 poms with source-version 1.5 or 30 poms using junit 3.8.2 is going to make upgrading to java 6 or junit 4.4 that much harder.
Hope this helps.
I've been happily using the Multi-module Enterprise Project layout from Maven by Example. Read it through for inspiration and work it into what works for you..
Here's a few pointers:
Declare dependency versions in a common parent or use declare the versions in a specific project's dependencyManagement and reference it with import scope.
Avoid unversioned plugins. Declare plugin versions in a pluginManagement section.
Declare common plugin configurations in a parent pom, particularly reporting configurations.
Don't declare repositories in your POMs.
Use a repository manager like Nexus
Use properties to allow child projects to inherit configuration, but override key values (e.g. in the url for distributionManagement)
Set up a continuous integration server. Projects in development should have SNAPSHOT versions and be deployed to the repository regularly.
It's all adjustment. Maven don't have all nor latest. mine here saved me you may look and just feel what's right for you.
<?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/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.appspot.classifiedsmarket</groupId>
<artifactId>classifiedsmarket</artifactId>
<packaging>war</packaging>
<version>1.0-SNAPSHOT</version>
<name>classifiedsmarket Maven Webapp</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.12</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>httpunit</groupId>
<artifactId>httpunit</artifactId>
<version>1.6.1</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>struts</groupId>
<artifactId>struts</artifactId>
<version>1.2.9</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.6</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>informa</groupId>
<artifactId>informa</artifactId>
<version>0.6.0</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.jasypt</groupId>
<artifactId>jasypt</artifactId>
<version>1.3</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>htmlunit</groupId>
<artifactId>htmlunit</artifactId>
<version>1.9</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>javax.activation</groupId>
<artifactId>activation</artifactId>
<version>1.1</version>
</dependency>
<dependency>
<groupId>javax.mail</groupId>
<artifactId>mail</artifactId>
<version>1.4</version>
</dependency>
<dependency>
<groupId>dwr</groupId>
<artifactId>dwr</artifactId>
<version>1.1.3</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>commons-dbcp</groupId>
<artifactId>commons-dbcp</artifactId>
<version>1.2.2</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>commons-pool</groupId>
<artifactId>commons-pool</artifactId>
<version>1.4</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>jstl</groupId>
<artifactId>jstl</artifactId>
<version>1.1.2</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>taglibs</groupId>
<artifactId>standard</artifactId>
<version>1.1.2</version>
<scope>compile</scope>
</dependency>
</dependencies>
<build>
<finalName>classifiedsmarket</finalName>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>RELEASE</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>RELEASE</version>
<configuration>
<encoding>UTF-8</encoding>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>RELEASE</version>
<configuration>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
</plugins>
</build>
<properties>
<netbeans.hint.deploy.server>Tomcat55</netbeans.hint.deploy.server>
</properties>
</project>