Is it possible to use maven and dependency-check-maven plugin to validate contens of already built ear file ? I'm trying something like below but I have no idea where I could point file which I want to verify
<build>
<plugins>
<plugin>
<groupId>org.owasp</groupId>
<artifactId>dependency-check-maven</artifactId>
<version>6.1.6</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
I've found resolution. I point directory under plugin level. It forces plugin to check all files placed there
<configuration>
<scanSet>
<fileSet>
<directory>\f1\f2\f3</directory>
</fileSet>
</scanSet>
</configuration>
Related
Is there a well-known way to create an uber source jar? In other words, a jar of all the source code for a project and all its dependencies (or at least those that have a -sources.jar)?
I've looked into doing it with the maven-assembly-plugin, but using a dependencySet with includes of *.*.*.sources.* (or *.sources) doesn't work because those are not actually dependencies of the project, and I don't want to add them all.
You can use the maven-shade-plugin to create an uber jar. Just include the following within your <build> tag -
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<id>source-jar</id>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<createSourcesJar>true</createSourcesJar>
<artifactSet>
<includes>
<include>...</include>
</includes>
</artifactSet>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
To modify the configuration, you can use Resource Transformers within org.apache.maven.plugins.shade.resource package.
And to define the contents of the jar, you can further use includes and excludes within the filters.
I found some information on working with sources in the maven-dependency-plugin.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>src-dependencies</id>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<phase>prepare-package</phase>
<configuration>
<classifier>sources</classifier>
<failOnMissingClassifierArtifact>false</failOnMissingClassifierArtifact>
<outputDirectory>${project.build.directory}/sources</outputDirectory>
<includeGroupIds>{your group prefix}</includeGroupIds>
<includes>**/*.java</includes>
<includeScope>runtime</includeScope>
</configuration>
</execution>
So if I do that, and then run a maven-assembly-plugin referencing the unpacked files, I can do it in two steps.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<execution>
<id>uber-source</id>
<goals>
<goal>single</goal>
</goals>
<phase>package</phase>
<configuration>
<descriptors>
<descriptor>ubersource.xml</descriptor>
</descriptors>
<outputDirectory>${deploy.internal.directory}</outputDirectory>
<finalName>${project.artifactId}</finalName>
</configuration>
</execution>
</executions>
</plugin>
with a file set in the assembly descriptor ubsersource.xml:
<fileSet>
<directory>${project.build.directory}/sources</directory>
<outputDirectory>.</outputDirectory>
</fileSet>
And then I get my uber source jar...
There is perhaps a subtle distinction in the way the maven-assembly-plugin and maven-dependency-plugin treats sources. If you reference classifier sources in a dependencySet of an assembly descriptor, it looks for sources that are actual dependencies in your pom -- not that useful. However, in maven-dependency-plugin, referencing sources classifier means that sources of your dependencies. Hence why this solution works.
I also wrapped this up in my own plugin using mojo-executor to make it single step, and single declaration in my pom, but that's optional
This is a lot more pom code, but I like it better than the maven-shade-plugin because it does just what I want, and nothing more.
Dealing with a legacy project, I have the need to load text resources from a jar at an URL.
The text resources will be then filtered and included in the output; those resources come from a released artifact.
From resource-plugin I see it is only possible to give a number of directories; would it be possible to load resources as I need?
I want to do somthing like this, but using a remote jar instead of the oher project in the workspace:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<executions>
<execution>
<id>copy-resources</id>
<phase>process-resources</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/${project.build.finalName}</outputDirectory>
<resources>
<resource>
<directory>../<another project on the same workspace>/src/main/filtered-resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
Remote resource plugin, as suggested in one of the answer doesn't work because no file from the imported bundle ends up in target; there is no way I can produce the original bundle using remote resource plugin (it's a legacy projetc still in use and completely out of my control).
I think the Maven Remote Resources Plugin will suit your needs.
EDIT:
Snippet obtained from the usage page of the plugin. That XML fragment will attach the plugin to the generate-sources phase (choose a different one if it doesn't fit your needs), will download the apache-jar-resource-bundle artifact and uncompress its contents into ${project.build.directory}/maven-shared-archive-resources.
For better results is recommended that the resources artifact had been created using the bundle goal of the same plugin.
<!-- Turn this into a lifecycle -->
<plugin>
<artifactId>maven-remote-resources-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>process-remote-resources</id>
<phase>generate-sources</phase>
<goals>
<goal>process</goal>
</goals>
<configuration>
<resourceBundles>
<resourceBundle>org.apache:apache-jar-resource-bundle:1.0</resourceBundle>
</resourceBundles>
</configuration>
</execution>
</executions>
</plugin>
EDIT 2: Alternative Solution using AntRun
If your artifacts don't suit Maven needs and you need something more customized, then using AntRun plugin you could get it somehow:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<id>download-remote-resources</id>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<get src="URL of the resource" dest="${project.build.directory}" />
<unzip src="${project.build.directory}/filename.[jar|zip|war]" dest="${project.build.directory}/${project.build.finalName}" />
</target>
</configuration>
</execution>
</executions>
</plugin>
I'm new to maven, and found myself stuck with something which is really bothering me.
I have a multi-module project, and my parent pom.xml contains the following plugin:
<plugin>
<artifactId>maven-remote-resources-plugin</artifactId>
<executions>
<execution>
<id>process-remote-resources</id>
<goals>
<goal>process</goal>
</goals>
<configuration>
<resourceBundles>
<resourceBundle>
${shared.resources.version}
</resourceBundle>
</resourceBundles>
<includes>
<include>version.info</include>
</includes>
</configuration>
</execution>
</executions>
</plugin>
This code generates a version.info file and places them in each of my module jar files.
I was wondering if it's possible to make this code create the version.info file for only 2 modules out of the 3.
For example if I have modules: A, B and C.
I would like the version.info file to be in A and B but not in C.
I hope I explained myself well enough, in case not please let me know.
Thanks in advance,
Meny
Best solution would be moving this plugin configuration to the project/build/pluginManagement element of the parent pom:
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-remote-resources-plugin</artifactId>
<executions>
<execution>
<id>process-remote-resources</id>
<goals>
<goal>process</goal>
</goals>
<configuration>
<resourceBundles>
<resourceBundle>
${shared.resources.version}
</resourceBundle>
</resourceBundles>
<includes>
<include>version.info</include>
</includes>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
and call it at project/build/plugins in module poms:
<plugins>
<plugin>
<artifactId>maven-remote-resources-plugin</artifactId>
</plugin>
</plugins>
if such refactoring of parent pom is not allowed then override plugin configuration with skip set into true or use the none phase to disable unwanted plugin calls:
http://thomaswabner.wordpress.com/2010/02/16/howto-disable-inherited-maven-plugin/
I have a project expected to deliver a jar file:
<packaging>jar</packaging>
but the jar is built in a custom way, so the default packaging done with jar:jar has been disabled
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.2</version>
<executions>
<execution>
<id>default-jar</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
but then when I want to apply shade:shade on the existing jar I get an error
The project main artifact does not exist.
I assume that maven doesn't know about the .jar file created by my custom tool. How to let it know, because antrun attachArtifact doesn't work
<attachartifact file="./bin/classes.jar" classifier="" type="jar"/>
the error I get is
An Ant BuildException has occured: org.apache.maven.artifact.InvalidArtifactRTException: For artifact {:jar}: An attached artifact must have a different ID than its corresponding main artifact.
So this is not the method to register main artifact... Is there any (without writing custom java plugin)?
Thanks,
Lukasz
I checked the sources of JarMojo and it gave me an idea how to solve it with Groovy (via gmaven)
<plugin>
<groupId>org.codehaus.gmaven</groupId>
<artifactId>gmaven-plugin</artifactId>
<version>1.3</version>
<executions>
<execution>
<id>set-main-artifact</id>
<phase>package</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<source>
project.artifact.setFile(new File("./bin/classes.jar"))
</source>
</configuration>
</execution>
</executions>
</plugin>
and it works!:)
Something like this
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<id>attach-artifacts</id>
<phase>package</phase>
<goals>
<goal>attach-artifact</goal>
</goals>
<configuration>
<artifacts>
<artifact>
<file>${basedir}/bin/classes.jar</file>
<type>jar</type>
</artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
While your solution may work for a build to the install+ phase or where there are no dependencies in the reactor, in cases where only building to the compile or test phase the unpackaged classes won't be found by dependencies.
Building to compile happens when using plugins like the maven-release-plugin.
Extending your chosen solution to include identifying the unpacked classes during compile
<plugin>
<groupId>org.codehaus.gmaven</groupId>
<artifactId>gmaven-plugin</artifactId>
<version>1.3</version>
<executions>
<execution>
<id>set-main-artifact-compile</id>
<phase>compile</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<source>
project.artifact.setFile(new File("./bin/classes"))
</source>
</configuration>
</execution>
<execution>
<id>set-main-artifact</id>
<phase>package</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<source>
project.artifact.setFile(new File("./bin/classes.jar"))
</source>
</configuration>
</execution>
</executions>
</plugin>
By default the maven-install-plugin will use the identified artifact along the lines of
${project.build.directory}/${project.finalname}.jar
So another option might go something like this
<build>
<directory>bin</directory>
<outputDirectory>bin/classes</outputDirectory>
<finalName>classes</finalName>
</build>
We were having the same problem, with getting the "attached artifact must have a different ID than its corresponding main artifact" error. We found the solution in the following excellent blog post:
embed-and-run-ant-tasks-and-scripts-from-maven
As detailed in this section, you can fix the problem by adding a classifier so Maven can distinguish between the ant-built jar and the maven-built jar. Since you're using antrun attachartifact, you'd need this:
<attachartifact file="./bin/classes.jar" classifier="foo" type="jar"/>
Note you'll also need to include that classifier (along with groupId, artifactId and version) whenever you want to grab this jar as a dependency in other projects.
I'm building a web application project using maven, and packaging is set to "war". I also use YUI compressor plugin to compress javascript codes in the webapp directory. I've set up the YUI compressor like this:
<plugin>
<groupId>net.alchim31.maven</groupId>
<artifactId>yuicompressor-maven-plugin</artifactId>
<version>1.3.0</version>
<executions>
<execution>
<phase>process-resources</phase>
<goals>
<goal>compress</goal>
</goals>
</execution>
</executions>
<configuration>
<excludes>
<exclude>**/ext-2.0/**/*.js</exclude>
<exclude>**/lang/*.js</exclude>
<exclude>**/javascripts/flot/*.js</exclude>
<exclude>**/javascripts/jqplot/*.js</exclude>
</excludes>
<nosuffix>true</nosuffix>
<force>true</force>
<jswarn>false</jswarn>
</configuration>
</plugin>
If I do: mvn process-resources, src/main/webapp will get copied over to target/webapp-1.0/ directory, and javacripts are compressed. However, when I run mvn install, all the compressed javascripts are overwritten, apparently the packaging process copies the content from main/webapp one time before building the war file.
How can I get around this?
As you noticed, the /src/main/webapp dir (aka warSourceDirectory) contents is not copied into the project dir for packaging until the war plugin executes during the package phase. When the war plugin completes the archive is already built; too late to modify those resources. If the .js files you want to compress were moved into another directory (outside of /src/main/webapp) then you could do something like the below.
To test, I created a ${basedir}/src/play directory with a couple of files in it. I used the resource plugin for the example; you'd replace that config with the YUI compressor plugin config you needed and simply add the <webResource> element to your war plugin config as shown below; more info in the war plugin examples. My war ended up with the additional files right where I wanted them.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<executions>
<execution>
<id>copy-resources</id>
<phase>process-resources</phase>
<goals><goal>copy-resources</goal></goals>
<configuration>
<outputDirectory>${project.build.directory}/tmpPlay</outputDirectory>
<resources>
<resource>
<directory>${project.basedir}/src/play</directory>
<includes>
<include>**/*</include>
</includes>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<executions>
<execution>
<id>default-war</id>
<configuration>
<webResources>
<resource>
<directory>${project.build.directory}/tmpPlay</directory>
<targetPath>WEB-INF/yourLocationHere</targetPath>
<includes>
<include>**/*</include>
</includes>
</resource>
</webResources>
</configuration>
</execution>
</executions>
</plugin>
I think #user944849 answer is the correct answer, at least one of the correct answers. Another way of archiving this is to exclude the modified javascript directory from maven-war-plugin configuration, e.g.:
<plugin>
<artifactId> maven-war-plugin </artifactId>
<configuration>
<warSourceExcludes>**/external/ dojo/**/*.js </warSourceExcludes>
</configuration>
</plugin>
this will tell maven-war-plugin not to copy from the excluded directory, but since the modified javascript directory is already there, the war file still contains the javascript directory, BUT with the modified, in this case, compressed javascript codes.
in your execution directive, set the phase for applying your compression and copying to be install and that will hopefully do the trick. the code should be something like this:
<executions>
<execution>
....
<phase>install</phase>
....
</execution>
<executions>
Here is my solution, simply add an antrun plugin which updates the packaged war file using the processed outputs, which binds to the package phase:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>package</id>
<phase>package</phase>
<configuration>
<target>
<zip basedir="${project.build.directory}/${project.build.finalName}"
destfile="${project.build.directory}/${project.build.finalName}.war"
update="true">
</zip>
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>