Question: is there any way in Maven (without resorting to an ant plugin) to unzip a file, cd into the directory, remove the file, and the rezip it, all as part of the build?
This is necessary as it is a complex build and also do not want to have to use gradle to accomplish this task.
The requirement of unzipping, removing file and zipping again can also be met in one single step by the truezip-maven-plugin and its remove goal which:
Remove a set of files from an existing archive.
The official examples also cover this scenario.
Given the following snippet:
<properties>
<archive>${project.basedir}/sample.zip</archive>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>truezip-maven-plugin</artifactId>
<version>1.2</version>
<executions>
<execution>
<id>remove-a-file</id>
<goals>
<goal>remove</goal>
</goals>
<phase>package</phase>
<configuration>
<fileset>
<!-- note how the archive is treated as a normal file directory -->
<directory>${archive}</directory>
<includes>
<include>hello.txt</include>
</includes>
</fileset>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
And executing:
mvn clean package
The build will process the ${archive} file (in this case a sample.zip at the same level of the pom.xml file, that is, in the project.basedir directory) and remove from it the hello.txt file. Then rezip everything.
I just tested it successfully, you can even skip the properties section if not required. However, you should also carefully know that:
The zip file should not be under version control, otherwise it would create conflicts at each build
The behavior most probably should not be part of the default Maven build, hence good candidate for a Maven profile
the plugin replaces the original file, so if that was an issue you could firstly copy it to another location and then process it as above. To copy it, you could use the maven-resources-plugin and its copy-resources goal.
Related
I have a parent pom which is inherited by multiple other poms
superpom
|--pokemon
|--|--app
|--|--infrastructure
|--yu-gi-oh
|--|--app
|--|--infrastructure
I have multiple config files like:
a cve-suppress.xml file for the good old dependency plugin (can be directly on pom level)
logback.xml (must be in test/resources)
...
Of course, I could have these files in every project in every module, but changes would lead to changes everywhere and therefore consume much time.
How can I effectively move/copy the files on runtime to the child poms?
Does files are mostly used for testing in gitlab pipelines
Possible ideas
1. Resource Plugin in superpom
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>3.0.2</version>
<executions>
<execution>
<id>copy-resource-one</id>
<phase>generate-sources</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${basedir}/target/destination-folder</outputDirectory>
<resources>
<resource>
<directory>source-files</directory>
<includes>
<include>foo.txt</include>
</includes>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
superpom specifies path to resource
not working, because when e.g. pokemon executes plugin, in this scope, the file does not exist
2. Use Gitlab variables/files
copy files in gitlab pipelines to desired place
problem1 -> copy file to every test/resource folder in every module of project is hard and changes to path may lead to errors
problem2 -> file content is in gitlab therefore separeted from parent pom, overview might get blurry
3. Use mojo exec plugin
trigger script directly creating file
I am not sure how to do this exactly, I cannot find good examples so far :/
Do you have any other ideas? Is there a way I am missing or a dedicated plugon for this?
Sonatype has a repository that I want to deploy a jar file to, and they ask for separate files for application, sources, and javadocs:
Example:
example-application-1.4.7.pom
example-application-1.4.7.jar
example-application-1.4.7-sources.jar
example-application-1.4.7-javadoc.jar
In Scala SBT, I have a command called "package" that generates the jar file for the project, but that only generates "example-application-1.4.7.jar".
Question: What should I do to generate the other two jar files?
In Maven, in order to get the additional -sources and -javadoc artifacts, add to your POM file the following:
<build>
<plugins>
<!-- additional plugin configurations, if any.. -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.10.3</version>
<executions>
<execution>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Note the snippet above:
We are invoking the Maven Source Plugin to create an additional jar files for sources
We are invoking the Maven Javadoc Plugin to create an additional jar files for javadoc
Executing
mvn clean package
You will find these two additional jars in the target folder.
The .pom file instead is generated during the install phase, but it is not placed under the target folder. Basically, it is a copy of your pom.xml file, with a different extension and used by Maven during the dependency mediation process to check which transitive dependencies are required by the concerned artifact.
Executing
mvn clean install
Maven will install the artifact in your local cache (in your machine), under path_to_cache/.m2/repository/your_groupId/your_artifactId/your_version/. In this folder, you will also find the .pom file, which normally you don't need to distribute (it is created automatically by Maven).
Further note: you probably don't want to generate these additional jar files at each and every build, so to speed up normal builds and have them only on demand, you could wrap the snippet above in a Maven profile.
You can achieve this by removing the snippet above from your build section and add a further section at the end of your pom:
<profiles>
<profile>
<id>prepare-distribution</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.10.3</version>
<executions>
<execution>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
So that normal builds would not create these jars anymore, but when executing the following:
mvn clean install -Pprepare-distribution
You would instead get them back. the -P option is actually activating on demand the profile defined with the id prepare-distribution.
With Maven 3 a default profile already comes as part of the super pom which perform exactly the same actions (sources and javadoc artifact), hence no need to add anything to your existing project. Simply run:
mvn clean install -Prelease-profile
Or, to activate it via a property
mvn clean install -DperformRelease=true
However, as also specified in the super pom, this profile may be removed in future releases (although there since first Maven 3 version till version 3.3.9 so far)
NOTE: The release profile will be removed from future versions of the super POM
The main reason behind this warning is most probably to push for the usage of the Maven Release Plugin, which indirectly makes use of this profile via the useReleaseProfile option of the release:perform goal.
As highlighted by comments, if you are not familiar with maven (especially via console) I would definitely recommend to
Go through the official Maven in 5 minutes documentation for a quick but worthy look.
Play with Maven from the command line, is there where Maven gives you its best. IDE integrations are great, but command line is the real turning point.
Then play with the POM customization above, to get familiar with some concepts and behaviors, first directly as part of your default build, then moved to a profile.
Then, and only then, move to the Maven Release Plugin usage. I recommend it as last step because you would already have acquired more confidence and understanding and see it as less magic and more reasonable approach.
I have some java 7 annotation processors (for xtend) on my class-path. Via some annotations they create java files.
This works great, in Elipse and in the Maven build.
The generated files end up in target/generated-sources/annotations as expected.
The corresponding generated .class files also end up where expected and are thus part of the final jar file.
Since I need to also include all java source files in my .jar file (there should be only one .jar file with the sources and classes) for GWT,
I have specified src/main/java as a resources dir (so that Maven copies the files to the classes dir and they end up in the jar file).
the trick with the resources directory does not really work for my generated files, because Maven will first copy all resources and then start the compilation (which in turn will generate the .java files via the annotation processors).
How can I tell Maven to copy also include the generated .java files in the .jar?
You can bind the maven-resources-plugin to the prepare-package phase to achieve copying annotation sources before packaging proper:
<build>
<plugins>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<executions>
<execution>
<id>copy-annotations</id>
<phase>prepare-package</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<resources>
<resource>
<directory>target/generated-sources/annotations</directory>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
...
I hope that helps.
Cheers,
I'd like to add *.dlls as third party libs to my repository and during packaging process just pack them to *.jar, sign them and copy to some specific folder.
Signing and coping are well done and work correctly (as expected by using maven-dependency-plugin and maven-jarsigner-plugin). But I didn't find any method to automatically pack single dll to jar (without any sources like maven-assembly-plugin does).
Solution that I see by the time: add to my repository not a "pure" dll, but already packed to jar lib (packed by myself)... but it's not a good idea, I guess)
It sounds like you've successfully retrieved your .dll (with dependency plugin) and signed it (jarsigner plugin), and it's somewhere in your ${project.build.directory} (which defaults to target).
If that's correct, give this a try:
Define the packaging of your project as jar
Retrieve dlls
Make sure the jarsigner:sign goal is bound to the prepare-package phase. It binds to package by default and we need to ensure jarsigner:sign runs before jar:jar.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jarsigner-plugin</artifactId>
<version>1.2</version>
<executions>
<execution>
<id>sign</id>
<phase>prepare-package</phase> <!-- important -->
<goals>
<goal>sign</goal>
</goals>
</execution>
</executions>
</plugin>
Configure the jar plugin to include the signed dll(s)
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<!-- using this ID merges this config with default -->
<!-- So it should not be necessary to specify phase or goals -->
<!-- Change classes directory because it will look in target/classes
by default and that probably isn't where your dlls are. If
the dlls are in target then directoryContainingSignedDlls is
simply ${project.build.directory}. -->
<id>default-jar</id>
<configuration>
<classesDirectory>directoryContainingSignedDlls</classesDirectory>
<includes>
<include>**/*.dll</include>
</includes>
</configuration>
</execution>
</executions>
</plugin>
Now, running mvn clean package should give you a jar containing your signed dlls.
If JACOB requires manifest config there are docs explaining how to do this.
Good luck!
I would recommend to pack your dll's as a zip archive via maven-assembly-plugin and let that module deploy the zip archive as attached to your usual pom. The packaging of that project should be pom instead of default.
I would be a little bit confused if i download a jar and find dll's inside it,
but if you prefer you could create jar via the maven-assembly-plugin or use the maven-jar-plugin.
We have a Maven build (version 2.2.1) that currently produces a WAR file. Our output directory is target/, so we end up with a build artifact target/MyWar.WAR.
I'm adding two profiles to our POM.xml file to facilitate specific build "flavors" that each require a specific version of an A.xml file. In the intermediate build directory target/MyWar/ there are 3 files:
A.xml
A_1.xml
A_2.xml
Building in Maven without a specified profile should use A.xml, and it does currently. I want to use maven-antrun-plugin to (for Profile 1) replace A.xml with A_1.xml, and for Profile 2 replace A.xml with A_2.xml. (Removing the _1 and _2 suffixes.)
This is an example of Profile 1's execution:
<profile>
<id>Profile1</id>
<build>
...
<execution>
<id>Profile1-Replace</id>
<phase>package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<delete
file="${project.build.outputDirectory}/../MyWar/A.xml" />
<copy
file="${project.build.outputDirectory}/../MyWar/A_1.xml"
tofile="${project.build.outputDirectory}/../MyWar/A.xml" />
</tasks>
</configuration>
</execution>
...
</build>
</profile>
This correctly replaces the files in the intermediate target/MyWar/ directory, but for whatever reason the final WAR that's being produced in target does not reflect these changes.
It's as if running in the 'package' phase is too late, and the WAR has already been built. Changing the phase to 'compile' or 'test', the immediately-previous phases, complain because the A.xml file (and the intermediate build directory) have not even been created yet.
I would suggest to use the process-resources phase instead, or even generate-resources, if you feel that is a better fit. As a last resort, use prepare-package. But the package phase is the wrong place to do this sort of thing. All such modifications might typically occur directly in the source tree.
However, if you do the file manipulation in a separate directory, then you can add it during the package phase using the maven-war-plugin as follows:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<webResources>
<resource>
<directory>A_variant</directory>
</resource>
</webResources>
</configuration>
</plugin>
Of course if you need to go this route, it would be simpler to keep three directories and choose the appropriate one in your profile.