I am trying to have a project with packacking war where the jars are uncompressed. I thought it could be done like this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.6</version>
<configuration>
<recompressZippedFiles>true</recompressZippedFiles>
<archive>
<compress>false</compress>
</archive>
</configuration>
</plugin>
However the recompressZippedFiles parameter seems to be ignored, as all the jars in the WEB-INF/lib folder are the orginal, and thus compressed, ones (no matter if I remove the archive element or not).
I know that the default of recompressZippedFiles is already true. But no matter if I specify it or not, the jars are the original ones. I don't get fresh ones.
Any ideas?
I was asked about my use case: That war is used on several machines with virus scanners (e.g. Kaspersky) which are looking into every file, also those in archives. I need to reduce the time the virus scanners need to do so (without changing the settings of those scanners).
Related
I try to package an application into a jar file with maven. Somehow all files except .gitignore files are added to the jar.
Why is this file skipped and how can I disable this?
Even if I try to include it like below the include is ignored and the jar file remains empty.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<includes>
<include>**/.gitignore</include>
</includes>
</configuration>
</plugin>
maven-jar-plugin version: 3.1.0
maven version: 3.5.2
I tried this with a src/main/resources/.gitignore and it worked with the default maven-jar-plugin:2.4, i.e. .gitignore was packaged into the JAR.
Then I used the maven-jar-plugin:3.1.0 you mention and it did not work, as you describe.
It turned out that it doesn't work from v2.5 onwards.
I have the same issue with a .metadata folder in the target/classes folder. The .metadata folder is not included in the jar archive.
For me, it is not working with maven-jar-plugin:2.4 and upper. With version 2.3 it is working.
I submitted this issue : https://issues.apache.org/jira/browse/MJAR-265
The first thing is using a jar file example projects is astonishing. I would never expect to have example projects within a .jar file. The intention of a jar files is something different. I would suggest to use something more appropriate like .zip or .tar.gz etc. (This can be achieved with the maven-assembly-plugin) This will prevent accidental not intended use.
Apart from the whole problem is based on the definition of resources which are usually copied from src/main/resources to the target/classes directory. This is done by the maven-resources-plugin.
The maven-resources-plugin plugin has some kind of configuration which excludes some files which are usually not copied which contains .gitignore. So this means just putting a .gitignore file into src/main/resources will not produce the expected result nor using <includes>..</includes> configuration will not help here as well.
This means you need to change the default configuration of maven-resources-plugin via pluginManagement section like the following:
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>3.1.0</version>
<configuration>
<addDefaultExcludes>false</addDefaultExcludes>
</configuration>
</plugin>
Than the .gitignore file will be copied and should be packaged into the resulting jar file (Which I would not recommend to do.)
I've been tasked with reducing the download size of one of our webstart apps. I've figured that a decent portion of the download is from all a largish library of jar files, and since we rarely update many of them, it seems the download will be reduced significantly using the JNLP Version Download Protocol. This should stop the continual re-download of the same jars when a new version of the app is released.
Now, the project is build with maven. Part of the process is automatically generating a JNLP file from a velocity template. The resources section of the JNLP file is populated by a $dependencies variable assumedly passed in by maven and looks something like this:
<jar href="lib/mainjar-0.1.40-SNAPSHOT.jar" main="true"/>
<jar href="lib/somejar-1.1.jar"/>
<jar href="lib/someotherjar-1.0.jar"/>
<jar href="lib/anotherjar-1.6.0.jar"/>
etc...
It seems to me that maven is using its standard naming convention and constructing the jar names from the artifactId and version tags out of the project pom files.
How can I get it to use the JNLP naming convention instead?
I can change the velocity template to cut the $dependencies variable up and re-combine it with the JNLP convention - but that's only halfway what I need since the actual jar names need to be changed too.
The version download protocol article is about speeding up the check that resources are up to date. Although it may be useful as well, it is not the part that prevents re-downloading of the same files.
Webstart-maven-plugin can take care of versioning of the jars for you and they declare they use the version protocol as well. See http://www.mojohaus.org/webstart/webstart-maven-plugin/jnlp-mojo.html#outputJarVersions
My personal experience differs from what the docs say. It adds the version attribute for jars in the resulting jnlp and does not set the jnlp.versionEnabled property, which seems to be required for the version download protocol. Either way JWS works as I would expect - files are not re-downloaded when their version does not change.
Plugin setup:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>webstart-maven-plugin</artifactId>
<version>1.0-beta-6</version>
<dependencies>
<!--This dependency definition resolves class loading issue on Java 8 -->
<dependency>
<groupId>org.codehaus.mojo</groupId>
<artifactId>keytool-api-1.7</artifactId>
<version>1.4</version>
</dependency>
</dependencies>
<executions>
<execution>
<phase>process-resources</phase>
<goals>
<goal>jnlp-download-servlet</goal>
</goals>
</execution>
</executions>
<configuration>
<outputDirectoryName>/</outputDirectoryName>
<libPath/>
<sign>
<keystore>${basedir}/foo-key-store.jks</keystore>
<storepass>password</storepass>
<alias>foo-self-signed</alias>
<verify>true</verify>
</sign>
<unsign>true</unsign>
<jnlpFiles>
<jnlpFile>
<inputTemplate>template.vm</inputTemplate>
<outputFilename>foo.jnlp</outputFilename>
<jarResources>
<jarResource>
<groupId>foo.bar</groupId>
<artifactId>foo</artifactId>
<version>${project.version}</version>
<mainClass>foo.bar.Foo</mainClass>
<outputJarVersion>false</outputJarVersion>
</jarResource>
</jarResources>
</jnlpFile>
</jnlpFiles>
<gzip>true</gzip>
</configuration>
</plugin>
Excerpt from the generated foo.jnlp showing the version attribute of a dependency:
<jar href="commons-collections.jar" version="3.2.1"/>
And the file it references is named:
commons-collections-3.2.1.jar
I would like to pick a class file(StartEngine.class) from my WEB-INF/classes and put in the root directory of my WAR file to get below structure
process-engine.war
|
|-WEB-INF
|-js
|-StartEngine.class
|
I used of maven war but its not copying it. Please help me if anyone has any solution for the same.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.3</version>
<configuration>
<overlays>
<overlay>
<artifactId>process-engine</artifactId>
<excludes>
<includes>
<include>/WEB-INF/classes/StartEngine.class</include>
</includes>
<type>jar</type>
</overlay>
...
</plugins>
It looks like your configuration needs to be reworked. First of all, I suggest reading this page for a better understanding of overlays. There are a couple of possible situation which aren't clear to me from your question:
An overlay is supposed to come from a separate artifact. If you are indeed trying to pull in the StartEngine.class file from a separate artifact, then you'll need to add the groupId as well as the artifactId. Also since the class file is in a WEB-INF directory, then I'd suspect that this artifact would be of type 'war' (not jar).
If you are trying to move a file that is already in the project, then an overlay is not what you should use. Moving a class file to the base of the war file isn't a standard layout and if you must do this, then I suggest looking at the maven resources plugin's copy resources goal
My maven run creates different files in the target directory and compresses them into the jar file.
In case special characters like an Ü exist in the file names, the file names in the jar archive are not correctly encoded and showed as ├£. (The file contents are not affected)
As the files are correctly shown in the target directory, the issue must be caused by maven's jar:jar.
The interesting thing is that if I use the unzip command in Linux, the files are extracted with correct name, if I use Windows Explorer or 7zip in Windows, the names are not correct.
I had the exact same problem and upgrading my maven-war-plugin version solved the problem I think you should do the same with your maven jar plugin
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>3.0.0</version>
<configuration>
<attachClasses>true</attachClasses>
<classesClassifier>classes</classesClassifier>
</configuration>
</plugin>
</plugins>
short: I need to filter all .java files and every META-INF folder from a set of jars and package the class files and resources from that jars into one single jar.
I currently use the maven-assembly-plugin, but would try something else as long as it can easily be integrated into a maven build process.
long: I use maven to manage different stages of development for my tool. basic stage is freeware, second has some more features, third stage is all features)
That works fine so far, I use profiles to add the different source directories to the classpath and the sources are neatly compiled into the project.jar.
First problem: The .java sources included into the project via the profiles end up in the project.jar.
Then I use the maven-assembly-plugin to construct a final.jar that also contains the dependencies and in the end use launch4j to produce an executable for windows (the current target platform).
Second problem: The various META-INF parts from the dependency jars mix in the final.jar and I would want them all to be skipped.
I have searched for examples of the assembly.xml using the <exclude> tag, but did not find any that used my combination of dependencySet and <exclude>*.java</exclude>. I'm not even positive that I can do that.
Here is my assembly.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>jar-with-dependencies</id>
<formats>
<format>jar</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<dependencySets>
<dependencySet>
<outputDirectory>/</outputDirectory>
<useProjectArtifact>true</useProjectArtifact>
<unpack>true</unpack>
<scope>runtime</scope>
<useDefaultExcludes>true</useDefaultExcludes>
<!--<useTransitiveFiltering>true</useTransitiveFiltering>-->
<!--<useStrictFiltering>true</useStrictFiltering>-->
<excludes>
<exclude>META-INF</exclude>
<exclude>**/*.java</exclude>
<exclude>*.java</exclude>
<exclude>*:sources</exclude>
</excludes>
</dependencySet>
</dependencySets>
</assembly>
My research so far:
I have googled with example assembly.xml exclude java but could not find examples that covered my problem. (I have also googled a lot the past days but did not save all I found)
I have read http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html but could not apply that knowledge to my problem.
Okay, so I figured it out for me.
first: to filter out java and other source files from source parts that were included using profiles I use:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<mainClass>de.steamnet.oneClickWonder.awt.OCWController</mainClass>
</manifest>
</archive>
<excludes>
<exclude>**/*.java</exclude>
<exclude>**/*.form</exclude>
</excludes>
</configuration>
</plugin>
The task of filtering the META-INF from the dependencies has gone away when I started using an installer so now I can just deliver mulitple jars with their own META-INF.
So, as Michael-O stated this approach (using profiles to include additional source parts) may not be the correct one to do but it is very handy and I stick to it. With the excludes tag from the jar plugin the troubles with source files being added to the final jar also goes away.
This is absolutely the wrong way to go. Do never produce more than one main jar per artifact id. You should use this approach:
create for every main jar a single module.
set dependencies from say full to basic and so forth.
now you have to options to repackage your stuff. You either use the shade plugin which will include the artifact the way you want/need or you use the dependency:unpack-dependencies and put the stuff in the output dir.
After that your will end up with the "aggregated" jar files. Doing that with profiles and asm plugin simply does not scale.
After you have done that create another module for the tar.gz or your distro and depend on that main jars and bundle up your assembly. You are done!
Viel Erfolg und Gruß nach Düren