Is it somehow possible to specify a optional defaultconfmapping for ivy?
What im looking for is to specify in the defaultconfmapping to get all source jars, but some lib dont have source jars available, and those would be fine to skip.
something like:
<dependencies defaultconf="default" defaultconfmapping="default->default,sources(?onlyifavailable)" >
is this somehow possible in ivy?
Else is there a way to only specify to NOT get a conf target?
ie:
<dependency org="org.lib" name="example" rev="default->!sources" />
The main thing i'm looking for is a way to define all (most) configuration mappings in the defaultconfmapping and not duplicate these mappings on individual items.
This means i'm looking for either an option to 'get but ignore if not there' or 'only adjust this part of the mapping without having to duplicate the parts that are still the same'
(one of the reasons is the large amount of dependecies we have)
If you have an empty fallback, it essentially makes the configuration optional:
<dependencies defaultconf="default" defaultconfmapping="default->default,sources()" >
Default configuration mappings are defined on the optional configuration declaration within your ivy file:
For example
<configurations defaultconfmapping="compile->default;sources;javadoc">
..
..
This creates 3 configuration mappings (which I think is what you're looking for):
compile->default
sources->sources
javadoc->javadoc
Personally I prefer to default an explicit configuration mapping on each dependency, but that's more pendantic.
Example
The following example generates an ivy report for each configuration and saves the source and javadoc jars in specific directories:
├── build.xml
├── ivy.xml
└── target
├── ivy-reports
│ ├── com.myspotontheweb-demo-compile.html
│ ├── com.myspotontheweb-demo-javadoc.html
│ ├── com.myspotontheweb-demo-runtime.html
│ ├── com.myspotontheweb-demo-sources.html
│ ├── com.myspotontheweb-demo-test.html
│ └── ivy-report.css
├── javadoc
│ ├── junit-4.11-javadoc.jar
│ ├── slf4j-api-1.7.5-javadoc.jar
│ └── slf4j-log4j12-1.7.5-javadoc.jar
└── sources
├── junit-4.11-sources.jar
├── slf4j-api-1.7.5-sources.jar
└── slf4j-log4j12-1.7.5-sources.jar
build.xml
<project name="demo" default="resolve" xmlns:ivy="antlib:org.apache.ivy.ant">
<!--
================
Build properties
================
-->
<property name="build.dir" location="target"/>
<target name="resolve" description="Use ivy to resolve classpaths">
<ivy:resolve/>
<ivy:report todir='${build.dir}/ivy-reports' graph='false' xml='false'/>
<ivy:cachepath pathid="compile.path" conf="compile"/>
<ivy:cachepath pathid="test.path" conf="test"/>
<ivy:retrieve pattern="${build.dir}/[conf]/[artifact]-[revision](-[classifier]).[ext]" conf="sources,javadoc"/>
</target>
</project>
ivy.xml
<ivy-module version="2.0">
<info organisation="com.myspotontheweb" module="demo"/>
<configurations defaultconfmapping="compile->default;sources;javadoc">
<conf name="compile" description="Required to compile application"/>
<conf name="sources" description="Source jars"/>
<conf name="javadoc" description="Javadoc jars"/>
<conf name="runtime" description="Additional run-time dependencies" extends="compile"/>
<conf name="test" description="Required for test only" extends="runtime"/>
</configurations>
<dependencies>
<!-- compile dependencies -->
<dependency org="org.slf4j" name="slf4j-api" rev="1.7.5"/>
<!-- runtime dependencies -->
<dependency org="org.slf4j" name="slf4j-log4j12" rev="1.7.5" conf="runtime->default;sources;javadoc"/>
<!-- test dependencies -->
<dependency org="junit" name="junit" rev="4.11" conf="test->default;sources;javadoc"/>
</dependencies>
</ivy-module>
Related
0.4 started this week so our team created a new directory when the first changelog was created.
Should we create a v0.3 even though there was no Liquibase changelogs introduced, but there was an application release of v0.3.
What's the best practice here?
.
├── changelog-root.xml
├── v0.1
│ ├── 1661285844-initialschema.xml
│ └── 1661285857-createstudenttable.xml
├── v0.2
│ └── 1661295851-agecolumnonstudent.xml
└── v0.4
└── 1661395851-studentagechangetype.xml
changelog-root.xml is the top level changelog and includes references to all other changelogs:
<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog
xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
xmlns:pro="http://www.liquibase.org/xml/ns/pro"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-latest.xsd
http://www.liquibase.org/xml/ns/dbchangelog-ext http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd
http://www.liquibase.org/xml/ns/pro http://www.liquibase.org/xml/ns/pro/liquibase-pro-latest.xsd">
<includeAll path="v0.1/"/>
<includeAll path="v0.2/"/>
<includeAll path="v0.4/"/>
</databaseChangeLog>
We have a repository which doesn't have ivy.xml and other metadata files. Since, its published by another team which doesn't use ivy/maven but will continue to deliver code frequently.
The jars needed for dependency are stored in flat structure inside a single directory with no revision data. The organization / module /revision structure is absent.
Does ivy allow such dependency resolutions in the core product or will I have to write a custom resolver?
Thanks
The standard resolvers should be able to pick up the atifacts (url, filesystem, etc). The problem you'll face is that, by default, ivy assumes a revision never changes. Without version information you're going to have tweak the standard resolver settings to force ivy to always check the artifact.
The ivy concepts page explains how this works:
Some people, especially those coming from maven 2 land, like to use one special revision to handle often updated modules. In maven 2 this is called a SNAPSHOT version, and some argue that it helps save disk space to keep only one version for the high number of intermediary builds you can make whilst developing.
Ivy supports this kind of approach with the notion of "changing revision". A changing revision is just that: a revision for which Ivy should consider that the artifacts may change over time. To handle this, you can either specify a dependency as changing on the dependency tag, or use the changingPattern and changingMatcher attributes on your resolvers to indicate which revision or group of revisions should be considered as changing.
Personally I dislike this kind of dependency management. Your build is a moving goal post and it's hard to keep it stable.
I would encourage to to persuade the other team to at least append a build number to each artifact they publish. Your ivy build could then use a dynamic revision to resolve the artifact. The key point is that when you ship your code, your module will have a dependency against a specific version of its 3rd party libraries.
Update
The following is an example project. It uses Maven Central and a local repo, to download its dependencies.
├── build
│ ├── compile
│ │ ├── artifact1.jar <-- Changing artifact
│ │ └── slf4j-api.jar
│ ├── runtime
│ │ ├── artifact1.jar <-- Changing artifact
│ │ ├── artifact2.jar <-- Changing artifact
│ │ ├── log4j.jar
│ │ ├── slf4j-api.jar
│ │ └── slf4j-log4j12.jar
│ └── test
│ ├── artifact1.jar <-- Changing artifact
│ ├── artifact2.jar <-- Changing artifact
│ ├── artifact3.jar <-- Changing artifact
│ ├── hamcrest-core.jar
│ ├── junit.jar
│ ├── log4j.jar
│ ├── slf4j-api.jar
│ └── slf4j-log4j12.jar
├── build.xml
├── ivysettings.xml
└── ivy.xml
The local repo is un-versioned and has no ivy files. Normally the ivy resolvers require ivy files (or POM in the case of Maven) to determine if a remote module has changed. In the absence of metadata you can mark the dependency as changing in the ivy file.
build.xml
<project name="demo" default="build" xmlns:ivy="antlib:org.apache.ivy.ant">
<target name="build" description="do something">
<ivy:retrieve pattern="build/[conf]/[artifact].[ext]"/>
</target>
<target name="clean" description="Cleanup build files">
<delete dir="build"/>
</target>
<target name="clean-all" depends="clean" description="Additionally purge ivy cache">
<ivy:cleancache/>
</target>
</project>
Notes:
Stand build file using ivy. The retrieve task assembles the files into their various configuration groupings.
ivy.xml
<ivy-module version="2.0">
<info organisation="com.myspotontheweb" module="demo"/>
<configurations>
<conf name="compile" description="Required to compile application"/>
<conf name="runtime" description="Additional run-time dependencies" extends="compile"/>
<conf name="test" description="Required for test only" extends="runtime"/>
</configurations>
<dependencies>
<!-- compile dependencies -->
<dependency org="org.slf4j" name="slf4j-api" rev="1.7.5" conf="compile->default"/>
<dependency org="myorg" name="artifact1" rev="NA" conf="compile->default" changing="true"/>
<!-- runtime dependencies -->
<dependency org="org.slf4j" name="slf4j-log4j12" rev="1.7.5" conf="runtime->default"/>
<dependency org="myorg" name="artifact2" rev="NA" conf="runtime->default" changing="true"/>
<!-- test dependencies -->
<dependency org="junit" name="junit" rev="4.11" conf="test->default"/>
<dependency org="myorg" name="artifact3" rev="NA" conf="test->default" changing="true"/>
</dependencies>
</ivy-module>
Notes:
The "myorg" dependencies have a dummy "NA" entry as their revision and are marked as "changing".
ivysettings.xml
<ivysettings>
<settings defaultResolver="central" />
<resolvers>
<ibiblio name="central" m2compatible="true"/>
<url name="myorg-repo">
<artifact pattern="http://localhost:8080/userContent/[artifact].[ext]"/>
</url>
</resolvers>
<modules>
<module organisation="myorg" resolver="myorg-repo"/>
</modules>
</ivysettings>
Notes:
The "myorg-repo" resolver is setup to download only the "myorg" dependencies. This enables all other dependencies to be resolved by Maven Central.
The "myorg-repo" resolver just declares an artifact pattern, I'm assuming there are no ivy files to be retrieved.
Understanding ivy pattern helped me resolve the issue. The catch is never specify an ivy pattern whenever the repository doesn't have ivy files.
In Maven 2, I was able to set profile properties like these:
<profiles>
<profile>
<id>test</id>
<properties>
<region>test</region>
<application-url>http://localhost:8080/myTestApp</application-url>
<cookie-name>TestCookie</cookie-name>
</properties>
</profile>
<profile>
<id>production</id>
<properties>
<region>production</region>
<application-url>http://prodserver/myProductionApp</application-url>
<cookie-name>ProductionCookie</cookie-name>
</properties>
</profile>
<profiles>
At compile time Maven would replace these configuration values in my spring beans. For instance, if I had a spring bean defined like this:
<bean id="cookie-name" class="java.lang.String">
<constructor-arg value="${cookie-name}"/>
</bean>
and I specified -P test when i build the project, Maven would set the set the bean to look like
<bean id="cookie-name" class="java.lang.String">
<constructor-arg value="TestCookie"/>
</bean>
and when I specified -P production, maven again replaced the text with the correct property
<bean id="cookie-name" class="java.lang.String">
<constructor-arg value="ProductionCookie"/>
</bean>
As the number of environments and customers we support has increased, I've been taking more advantage of this functionality.
I've tried to upgrade to Maven 3, but it seems like this behavior has disappeared or is broken. I can't seem to find what it has been replaced by.
Anyone have any insights on how or if I can upgrade to Maven3 while preserving this behavior?
I've tried to upgrade to Maven 3, but it seems like this behavior has disappeared or is broken. I can't seem to find what it has been replaced by.
Resources filtering just works fine with Maven 3. Given the following project structure:
.
├── pom.xml
└── src
├── main
│ ├── java
│ │ └── com
│ │ └── stackoverflow
│ │ └── App.java
│ └── resources
│ └── beans.xml
└── test
└── java
└── com
└── stackoverflow
└── AppTest.java
With the following pom.xml:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.stackoverflow</groupId>
<artifactId>Q4206883</artifactId>
<version>1.0-SNAPSHOT</version>
...
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
<profiles>
<profile>
<id>test</id>
<properties>
<region>test</region>
<application-url>http://localhost:8080/myTestApp</application-url>
<cookie-name>TestCookie</cookie-name>
</properties>
</profile>
<profile>
<id>production</id>
<properties>
<region>production</region>
<application-url>http://prodserver/myProductionApp</application-url>
<cookie-name>ProductionCookie</cookie-name>
</properties>
</profile>
</profiles>
</project>
And where beans.xml contains:
<bean id="cookie-name" class="java.lang.String">
<constructor-arg value="${cookie-name}"/>
</bean>
Running maven with any of the profiles e.g.:
$ mvn -P test process-resources
[INFO] Scanning for projects...
...
Produces the expected result:
$ cat target/classes/beans.xml
<bean id="cookie-name" class="java.lang.String">
<constructor-arg value="TestCookie"/>
</bean>
Tested with:
$ mvn --version
Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
Java version: 1.6.0_22
Java home: /usr/lib/jvm/java-6-sun-1.6.0.22/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux" version: "2.6.35-22-generic" arch: "i386" Family: "unix"
If this is not what you get, please provide some pieces allowing to reproduce.
Can only post 1 link at a time and apparently only one answer every 3 minutes :-(
http://jira.codehaus.org/browse/MRESOURCES-117
The latest released version (2.4.3) of the maven-resources-plugin is broken.
http://jira.codehaus.org/browse/MRESOURCES-104
i am new to maven.
i have a Java EE Web project and a model project,web project is depend on model because module has some standard classed which need to be jar in web.
web needs model jar file.
how can i write the 2 projects which one is depend on another ?
give me a sample coding on both project pom.
A typical maven multi-modules project structure would involve 3 modules here: an aggregating parent module (allowing to start a multi-module build on all modules), the model module and the web module. Something like this:
.
├── mymodule
│ ├── pom.xml
│ └── src
│ ├── main
│ │ ├── java
│ │ └── resources
│ └── test
│ ├── java
│ └── resources
├── mywebapp
│ ├── pom.xml
│ └── src
│ └── main
│ ├── resources
│ └── webapp
│ ├── index.jsp
│ └── WEB-INF
│ └── web.xml
└── pom.xml
Where the parent pom.xml (at the root) would be 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>
<groupId>com.stackoverflow</groupId>
<artifactId>Q4176120</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>pom</packaging>
<name>Q4176120 - Parent POM</name>
<url>http://maven.apache.org</url>
<dependencies>
...
</dependencies>
<modules>
<module>mywebapp</module>
<module>mymodule</module>
</modules>
</project>
The mymodule/pom.xml would be a regular 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 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<artifactId>Q4176120</artifactId>
<groupId>com.stackoverflow</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<!--groupId>com.stackoverflow</groupId--> <!-- inherited -->
<artifactId>mymodule</artifactId>
<packaging>jar</packaging>
<name>Q4176120 - Module</name>
<dependencies>
...
</dependencies>
</project>
And mywebapp/pom.xml would declare a dependency on the mymodule artifact:
<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>
<parent>
<artifactId>Q4176120</artifactId>
<groupId>com.stackoverflow</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<!--groupId>com.stackoverflow</groupId--> <!-- inherited -->
<artifactId>mywebapp</artifactId>
<packaging>war</packaging>
<name>Q4176120 - Maven Webapp</name>
<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>mymodule</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
<build>
<finalName>Q4176120</finalName>
</build>
</project>
With this structure, you can start a multi-modules build from the parent directory i.e. run a goal on all modules (and maven will calculate the right build order):
$ mvn install
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] Q4176120 Parent POM
[INFO] Q4176120 Module
[INFO] Q4176120 Maven Webapp
[INFO]
...
Note that I also used inheritance in the above samples (mymodule and mywebapp inherit from a parent that is declared in the <parent> element) so that I can group common parts in a parent POM and avoid repeating things. This is not mandatory, you can use aggregation without inheritance but this is very handy and aggregation and inheritance often go together in practice.
Resources
Maven Documentation
Project Inheritance vs Project Aggregation
Maven Book
3.6.2. Multi-module vs. Inheritance
You create 2 maven projects: web project and jar project. web project will depend on the model project. So you will add the model project as a dependency in the web projects pom.xml
I suggest you read maven basics here: http://www.sonatype.com/books/maven-book/
You model project pom.xml might look 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/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.abc</groupId>
<artifactId>>model-module</artifactId>
<name>My Model Module</name>
<packaging>jar</packaging>
<version>1.0.0-SNAPSHOT</version>
Your web app pom.xml might look like this. notice the dependencies section
<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.abc</groupId>
<artifactId>>my-web-app</artifactId>
<name>My First Web Application</name>
<packaging>war</packaging>
<version>1.0.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>com.abc</groupId>
<artifactId>model-module</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
I'm starting to work with Maven but am not yet successfully thinking in Maven's terms. I have a specific requirement and the docs aren't giving me enough clues, so I could use a bit of help:
I'd like to create an assembly that
builds a jar-with-dependencies like the "standard" target of this name, but excluding a couple of the resources. I want log4j.properties and a couple of other configuration files to not be in the jar.
builds a .ZIP file containing in its root directory the .jar from step 1 as well as the above mentioned config files.
I want to fire this assembly up from the command line (only), hence no need to tie to a phase (or goal? mojo?). Preferrably using either assembly:assembly or assembly:single.
Do I need a custom assembly descriptor for this?
And is it true I can't nest it in the pom.xml? So it goes in src/assembly/something.xml and gets referenced with a descriptorRef?
Can I code this as two relatively simple assemblies, of which one builds on the other (i.e. the .Zip assembly uses the .Jar assembly) or do I have to do everything in one assembly?
I'm starting to work with Maven but am not yet successfully thinking in Maven's terms.
Welcome on board, Carl! :D
I want to fire this assembly up from the command line (only), hence no need to tie to a phase (or goal? mojo?). Preferrably using either assembly:assembly or assembly:single.
Just to clarify: the build lifecycle itself is made of phases (compile, test, package, etc) and plugin goals (technically Mojos) are bound on phases. You then either invoke a phase... or just a specific plugin goal.
Do I need a custom assembly descriptor for this?
Well, since you want behavior that the pre-defined descriptors don't cover, yes. You'll even need two of them (of for the uberjar, one for the zip).
And is it true I can't nest it in the pom.xml? So it goes in src/assembly/something.xml and gets referenced with a descriptorRef?
Yes, that's true (descriptors use a custom format) and they usually go into src/main/assembly. And no, descriptorRef is for the built-in descriptors, you'll have to use descriptor here.
Can I code this as two relatively simple assemblies, of which one builds on the other (i.e. the .Zip assembly uses the .Jar assembly) or do I have to do everything in one assembly?
As hinted, you'll need two assembly descriptors. Let me help a bit...
Let's assume you have the following project structure:
$ tree .
.
├── pom.xml
└── src
├── main
│ ├── assembly
│ │ ├── jar.xml
│ │ └── zip.xml
│ ├── java
│ │ └── com
│ │ └── stackoverflow
│ │ └── App.java
│ └── resources
│ └── log4j.properties
└── test
└── java
└── com
└── stackoverflow
└── AppTest.java
Where the pom.xml contains the following configuration for the assembly plugin:
<project>
...
<dependencies>
...
</dependencies>
...
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2-beta-5</version>
<configuration>
<descriptors>
<descriptor>src/main/assembly/jar.xml</descriptor>
<descriptor>src/main/assembly/zip.xml</descriptor>
</descriptors>
</configuration>
</plugin>
</plugins>
</build>
</project>
The descriptor for the "filtered" uberjar (jar.xml) looks like this:
<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd">
<id>uberjar</id>
<formats>
<format>jar</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<dependencySets>
<dependencySet>
<unpack>true</unpack>
<scope>runtime</scope>
<useProjectArtifact>false</useProjectArtifact>
</dependencySet>
</dependencySets>
<fileSets>
<fileSet>
<directory>${project.build.outputDirectory}</directory>
<outputDirectory>/</outputDirectory>
<excludes>
<exclude>log4j.properties</exclude>
</excludes>
</fileSet>
</fileSets>
</assembly>
What this descriptor does is (in short):
include the dependencies, unpack them, but exclude the project itself (yes, this is counter intuitive but this weird default behavior has been kept for backward compatibility)
include the project files but exclude some of them.
And the descriptor for the zip (zip.xml) looks like this:
<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd">
<id>bin</id>
<formats>
<format>zip</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<fileSets>
<fileSet>
<directory>${project.basedir}/src/main/resources</directory>
<outputDirectory/>
<includes>
<include>log4j.properties</include>
</includes>
</fileSet>
<fileSet>
<directory>${project.build.directory}</directory>
<outputDirectory/>
<includes>
<include>*-uberjar.jar</include>
</includes>
</fileSet>
</fileSets>
</assembly>
Which is (somehow) self explaining :)
it includes the configuration files (relatively to <directory>) at the root of the assembly
it includes the uberjar (relatively to <directory>) at the root of the assembly
Finally, just run mvn assembly:assembly (that's the goal intended to be used on the CLI).
I didn't (knowingly) include META-INF/maven/** in the assembly for the uberjar. Is there a simple way to prevent inclusion of these?
These are coming from the libraries that are unpacked. You can exclude them using unpackOptions. Here is a modified version of the jar.xml:
<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd">
<id>uberjar</id>
<formats>
<format>jar</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<dependencySets>
<dependencySet>
<unpack>true</unpack>
<scope>runtime</scope>
<unpackOptions>
<excludes>
<exclude>META-INF/maven/**</exclude>
</excludes>
</unpackOptions>
<useProjectArtifact>false</useProjectArtifact>
</dependencySet>
</dependencySets>
<fileSets>
<fileSet>
<directory>${project.build.outputDirectory}</directory>
<outputDirectory>/</outputDirectory>
<excludes>
<exclude>log4j.properties</exclude>
</excludes>
</fileSet>
</fileSets>
</assembly>