I'm packaging an ejb and I need to include some .classes from a dependency into the jar, I'm trying to use the maven-dependency-plugin to unpack the artifact and put the files in my ${project.build.directory}/classes directory during the package phase, but when I execute mvn package I dont see any log or reference to the maven-dependency-plugin (nothing happens), I even tried putting a invalid version of the plugin and It doesn't even throw exceptions.
Below my pom.xml
....
<packaging>ejb</packaging>
<name>myapp</name>
...repository and props
<build>
<pluginManagement>
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<id>unpack</id>
<phase>package</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>com.myapp</groupId>
<artifactId>model</artifactId>
<version>1.0.0</version>
<type>jar</type>
<overWrite>true</overWrite>
<outputDirectory>${project.build.directory}/classes</outputDirectory>
<includes>**/shared/*.class</includes>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ejb-plugin</artifactId>
<version>2.3</version>
<configuration>
<ejbVersion>3.0</ejbVersion>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
<dependencies>
<dependency>
<groupId>com.myapp</groupId>
<artifactId>model</artifactId>
<version>1.0.0</version>
</dependency>
</dependencies>
what am I missing?
PS: the artifact model is installed in the local repo and I have tried with other phases too.
If you remove the lines containing the text <pluginManagement> and </pluginManagement> the plugin should execute. Just those two lines, not the lines in between. pluginManagement is a marginally advanced feature.
PluginManagement provides configuration details to POMs that inherit from this POM. However this section provides only the configuration details. To actually be executed, the plugin must be explicitly referred to outside of a pluginManagement section.
See POM Reference
Related
Is it possible to migrate from jars in maven flyway plugin? I have no problems with sqls and java (compiled to class) but no success with jars. Classpath is set correctly.
Ok, i've debugged the source code. Jar needs a special protocol that is being provided to it when it is placed in /jars catalog in flyway command line tool. There is no such an equivalent in a flyway maven plugin.
This is a slight workaround to the limitation of the flyway-maven-plugin executing from a jar artifact file containing multiple flyway SQL files.
Create a profile
Use the 'maven-dependency-plugin:unpack' to explode the content of your jar file to specific directory.
Run 'flyway-maven-plugin' with a 'location' limited to the extracted directory.
Not very pretty but works.
This is my sample profile
<profiles>
<profile>
<id>flyway</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>3.1.1</version>
<executions>
<execution>
<id>copy</id>
<phase>process-resources</phase>
<goals>
<goal>unpack</goal>
</goals>
</execution>
</executions>
<configuration>
<artifactItems>
<artifactItem>
<groupId>com.abc</groupId>
<artifactId>flyway</artifactId>
<version>1.0.0-SNAPSHOT</version>
<type>jar</type>
<overWrite>true</overWrite>
<outputDirectory>${project.build.directory}/jars</outputDirectory>
<destFileName>my-flyway.jar</destFileName>
</artifactItem>
</artifactItems>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>true</overWriteSnapshots>
</configuration>
</plugin>
<plugin>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>${flyway.version}</version>
<configuration>
<sqlMigrationSeparator>__</sqlMigrationSeparator>
<locations>
<location>filesystem:./target/jars/my-flyway.jar</location>
</locations>
<url>${flyway.url}</url>
<user>${flyway.user}</user>
<password>${flyway.password}</password>
<schemas>
<schema>my_schema</schema>
</schemas>
<baselineOnMigrate>true</baselineOnMigrate>
</configuration>
<dependencies>
<dependency>
<groupId>org.postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>${postgresql.version}</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</profile>
</profiles>
The maven command line is then
mvn -P flyway clean process-resources flyway:migrate
I am taking over a project which consists of around 15 projects, whose continuous integration practice was done (the practice was ceased and I need to re-start it in a new environment) by Maven + Nexus OSS + TeamCity and are developed using C#.
What I got, except for those C# solutions themselves, is a POM for each of these project, and another parent POM (which doesn't contain any code) which every other project has parent of. These development POMs only have inter-dependency on SNAPSHOT versions hence the build order is crucial. But these POMs that I have do not need any VS plugin, which means (I guess) the compile procedure is not done by Maven but by TeamCity (VS runner). The Maven scripts I have are probably only in charge of e.g., downloading dependencies, validating and installing/deploying/releasing. Unfortunately I can't find any TeamCity configurations so I have no clue how this was done before.
EDIT:
I'll try to put some POM and script file that I have and see if someone can see some clue on the build procedure.
The files I got from SVN are mainly in three kinds categories:
1) The C# source code and project/solution files. Each solution has a 'Dependency' folder which contains all the dependencies, both on other projects on third-party dlls, so that this solution can be built in VS by the developer right after he checkout this solution.
2) The (development) POMs.
Firstly I have the POM of the parent project. This project doesn't contain any code but only the POM and some scripts (other projects have similar files too). The POM looks like this:
<modelVersion>4.0.0</modelVersion>
<groupId>MY.GROUP</groupId>
<artifactId>configuration</artifactId>
<version>1.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
<name>Configuration</name>
...
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.8</version>
<executions>
<execution>
<id>purge-local-dependencies</id>
<phase>clean</phase>
<goals>
<goal>purge-local-repository</goal>
</goals>
<configuration>
<!-- Whether to purge only snapshot artifacts. -->
<snapshotsOnly>true</snapshotsOnly>
<actTransitively>false</actTransitively>
<reResolve>false</reResolve>
</configuration>
</execution>
<execution>
<id>unpack-dependencies</id>
<phase>validate</phase>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${dependencies.directory}</outputDirectory>
<markersDirectory>${dependencies.markers.directory}</markersDirectory>
<useBaseVersion>true</useBaseVersion>
<overWriteReleases>true</overWriteReleases>
<overWriteSnapshots>true</overWriteSnapshots>
<overWriteIfNewer>true</overWriteIfNewer>
<excludeTransitive>false</excludeTransitive>
<useSubDirectoryPerArtifact>true</useSubDirectoryPerArtifact>
<stripVersion>true</stripVersion>
<stripClassifier>true</stripClassifier>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<id>assembly-single-zip</id>
<phase>prepare-package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<finalName>${project.build.finalName}</finalName>
<descriptors>
<descriptor>${assembly.file}</descriptor>
</descriptors>
<attach>false</attach>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.8.1</version>
<executions>
<execution>
<id>deploy-file-snapshot</id>
<phase>verify</phase>
<goals>
<goal>deploy-file</goal>
</goals>
<configuration>
<file>${deploy.file}</file>
<repositoryId>${nexus.repository.id}</repositoryId>
<groupId>${project.groupId}</groupId>
<artifactId>${project.artifactId}</artifactId>
<version>${project.version}</version>
<url>${nexus.repository.url}</url>
<pomFile>${nexus.deploy.pom}</pomFile>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.5.2</version>
<configuration>
<preparationGoals>clean</preparationGoals>
<tagBase>${release.tagBase}</tagBase>
<tagNameFormat>#{project.version}</tagNameFormat>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
...
Here we see that the plugins used in the build are dependency (to download dependencies), 'assembly' (to package), deploy (to deploy files to Nexus) and release--frankly I can't figure out how it is used. The scripts that I have (I'll describe later) don't use it explicitly and it doesn't seem to be executed in other standard build phases.
And in each of the solution the POM has parent of the configuration. And they look like this:
ProjA
<parent>
<groupId>MY.GROUP</groupId>
<artifactId>configuration</artifactId>
<version>1.0.1-SNAPSHOT</version>
</parent>
<groupId>MY.GROUP</groupId>
<artifactId>ProjA</artifactId>
<version>1.1.2-SNAPSHOT</version>
<packaging>pom</packaging>
<name>ProjA</name>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
</plugin>
</plugins>
</build>
...
In ProjB which depends on ProjA, the POM is like this:
<parent>
<groupId>MY.GROUP</groupId>
<artifactId>configuration</artifactId>
<version>1.0.1-SNAPSHOT</version>
</parent>
<groupId>MY.GROUP</groupId>
<artifactId>ProjB</artifactId>
<version>1.2.1-SNAPSHOT</version>
<packaging>pom</packaging>
<name>ProjB</name>
...
<dependencies>
<dependency>
<groupId>MY.GROUP</groupId>
<artifactId>ProjA</artifactId>
<version>1.1.2-SNAPSHOT</version>
<type>zip</type>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
</plugin>
</plugins>
</build>
...
3) Then some .bat scripts as well as deploy.pom and release.pom.
The deploy pom and release pom just simply replace the version numbers and declare the dependencies:
deploy.pom for ProjA:
<?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>MY.GROUP</groupId>
<artifactId>ProjA</artifactId>
<version>1.1.2-SNAPSHOT</version>
<packaging>pom</packaging>
..<dependencies>...</dependencies>
By deploy I assume it means the the deployment of SNAPSHOT version as the version number indicates.
And the release.pom are basically the same but change the version to release version (in ProjA it is 1.1.1).
In each solution I also have some scripts which I believe are called by TeamCity. a) a file called download.bat, which basically calls mvn -U clean and then mvn -U validate. And b) a file called upload.bat which basically calls mvn prepare-package and then mvn verify. In both scripts we pass some mvn options like -DDeployPomFile, -DNexusUrl, -DRepositoryId. From the parent POM we can see some plugins are executed in those scripts too. And I guess the download.bat is called before TC is executing the VS build and upload.bat is called after the build (assume the target of the build is to publish the latest version).
Above is all I got. I suspect I still miss some TeamCity configuration because they are not stored in the SVN. But anyway, can somebody help figure out how to manage the daily build? Thank you very much!
For example, Java Maven project have ben compiled with maven-compiler-plugin with target level 1.7 have number of dependencies.
How to verify that those dependencies compiled with some specific Java target level as well (1.7 for example)?
As suggested in the comments, i have used Extra Enforcer Rules as additional dependency to Maven enforcer plugin that provides extra rules, as a solution.
The usage of this functionality described here, and specifically in my code it looks like that:
<properties>
<extra-enforcer-rules>1.0-beta-4</extra-enforcer-rules>
</properties>
<dependencies>
<dependency>
<groupId>org.codehaus.mojo</groupId>
<artifactId>extra-enforcer-rules</artifactId>
<version>${extra-enforcer-rules}</version>
</dependency>
</dependencies>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>enforce-bytecode-version</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<enforceBytecodeVersion>
<maxJdkVersion>1.7</maxJdkVersion>
</enforceBytecodeVersion>
</rules>
<fail>true</fail>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.codehaus.mojo</groupId>
<artifactId>extra-enforcer-rules</artifactId>
<version>${extra-enforcer-rules}</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</pluginManagement>
</build>
Using Artifactory and Maven, how can one refer to a dependency with the correct group/artifactId/version but use a filname that differs from the artifactId-version.end style?
The problem comes with a dll that cannot be renamed, and the mandatory? Artifactory naming convention.
edit
found one possible expensive way for this specific problem where the filename cannot include the dash-sign: creating a new Artifactory repository layout for which the pro-version is needed - so unfortunately, that is not an option!
partly solution for jUnit tests
using the maven-dependency-plugin and the maven-surefire-plugins one can make jUnits work. unfortunately, it does not solve the problem that the specific sapjco3.dll cannot be found when deployed within a war to a server.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.3</version>
<executions>
<execution>
<id>copy</id>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>sapjco</groupId>
<artifactId>sapjco3</artifactId>
<version>3.0.7</version>
<type>dll</type>
<classifier>win32</classifier>
<overWrite>true</overWrite>
<outputDirectory>${project.build.directory}/lib</outputDirectory>
</artifactItem>
</artifactItems>
<stripVersion>true</stripVersion>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<systemProperties>
<property>
<name>java.library.path</name>
<value>${project.build.directory}/lib</value>
</property>
</systemProperties>
</configuration>
</plugin>
</plugins>
</build>
Maven does not care for filenames, it cares for their coordinates. Add your DLL correctly to your remote repo and maven will do the rest.
A dependency snippet might be:
<dependency>
<groupId>com.company</groupId>
<artifactId>my.artifact</atifactId>
<version>1.0</version>
<type>dll</type>
<classifier>win32</classifier>
</dependency>
After you have done this, use either dependency:copy-dependencies or dependency:copy to change the filename at build time.
I have a parent pom with a few plugins. In my child pom, I want to exclude one plugin.
How can I do this?
I had a similar requirement to run some plugins in the child but not the parent POM. i achieved this by stating <skip>true</skip> in the parent POM.
the parent pom entry is below
<plugin>
<groupId>eviware</groupId>
<artifactId>maven-soapui-plugin</artifactId>
<version>4.0.0</version>
<inherited>false</inherited>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.2</version>
</dependency>
</dependencies>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
The child project pom entry is below
<plugins>
<plugin>
<groupId>eviware</groupId>
<artifactId>maven-soapui-plugin</artifactId>
<version>4.0.0</version>
<configuration>
<settingsFile>site-service-web/src/test/soapui/soapui-settings.xml</settingsFile>
<projectFile>site-service-web/src/test/soapui/PodifiSite-soapui-project.xml</projectFile>
<outputFolder>site-service-web/target/surefire-reports</outputFolder>
<junitReport>true</junitReport>
<exportwAll>true</exportwAll>
<printReport>true</printReport>
</configuration>
</plugin>
</plugins>
You can define all plugins in parent pom in pluginManagement section
<pluginManagement>
<plugins>
...
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.8</version>
<executions>
<execution>
<id>unpack-dependencies</id>
<phase>generate-sources</phase>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<includeTypes>tar.bz2</includeTypes>
<outputDirectory>${project.basedir}/target/dependencies</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
...
</plugins>
</pluginManagement>
And after in parent and child poms you can control the execution phase of this plugin
<plugins>
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<inherited>false</inherited>
<executions>
<execution>
<id>unpack-dependencies</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
</plugins>
If you paste this in parent pom do not forget option <inherited>false</inherited>, its disable execution inheritance in child pom.
You can declare all the plugins in your parent pom within <pluginManagement>. In each child, you can declare the plugins which are used by that child. This way, you can include or exclude plugins as appropriate.
You can look at this related SO discussion as well.
You could use a profile activated by a property to determine whether the plugin is used or not. By default the property could be activated and the one project you do not want to use it in could include the property value to exclude the plugin.