In a custom Maven plugin, I add a file as resource by using the addResource of MavenProject.
This works well for JAR projects, but for EARs, I see that the relevant file is copied to target/classes and then ignored. It is not present in the EAR.
There is an earSourceDirectory property which I can probably use to "trick" Maven by setting it to target/classes but it seems like the wrong way.
How can I handle generated resources that should be packed into an EAR?
The Maven EAR plugin completely disregard all of the "resources" directories that can be set up for a given artifact. Instead, as you mentioned, it solely relies on the directory referenced by the earSourceDirectory property, src/main/application being the default value. (see https://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#earSourceDirectory)
Therefore, you have two choices: either change that property value to point to target/classes as you proposed, or generate your files (as we did for one project) under src/main/application and then they will automatically be picked up by maven-ear-plugin.
Related
Is there a way we can load all the jar files inside a folder, as dependencies in a maven project.
So that, I do not have to mention each and every jar files in pom.xml, just mention or tell maven to pick all the jar files from folder 'x' and build the system.
Is this supported by maven?
I think this is supported by ant. Not sure whether gradle supports either.
In
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies
you see that you can reference single files, but there is no mechanism for directories. As I mentioned in the comment, using the disk is discouraged in general.
If you need the same set of dependencies in many projects, you can write a pom for that and use it (as parent or by setting a dependency to it).
Is dependency-reduced-pom.xml created by Maven shade plugin automatically used in projects that depends on the uberjar (instead of the ordinary pom.xml)?
Asking this after reading a number of dependency-reduced-pom.xml related questions and haven't found the answer yet:
Maven shade plugin adding dependency-reduced-pom.xml to base directory
What is the purpose of dependency-reduced-pom.xml generated by the shade plugin?
What is `dependency-reduced-pom.xml` file which created when calling maven package command?
The dependency-reduced-pom.xml is generated at build time into ${basedir} of the project. This file is a temporary file that is only used for packaging into the shaded jar. Quoting the documentation of the createDependencyReducedPom attribute:
Flag whether to generate a simplified POM for the shaded artifact. If set to true, dependencies that have been included into the uber JAR will be removed from the <dependencies> section of the generated POM. The reduced POM will be named dependency-reduced-pom.xml and is stored into the same directory as the shaded artifact. Unless you also specify dependencyReducedPomLocation, the plugin will create a temporary file named dependency-reduced-pom.xml in the project basedir.
To make it clear, after the maven-shade-plugin has run:
your initial POM will be left unchanged;
a temporary file that you can completely ignore named dependency-reduced-pom.xml will have been generated inside the root folder (this is considered an open issue with this plugin);
the shaded artifact will contain your initial POM unchanged inside the META-INF directory and not the reduced POM (this is not really important but better mention it - there was an issue about this that was closed automatically: MSHADE-36);
the POM that will be deployed is the reduced POM;
the shaded artifact will be by default the main artifact of the project.
When I use Maven Shade to build my assembly jar, some properties files will be replaced if they have the same file name, for example, "logback.xml". I have my own logback.xml in my project, however, it exists in other 3rd jars, too.
How can it be configured to use project's properties files in prior?
Thanks.
Hi you can try filtering out files that you dont want to be included. See here.
I want to include source files also in Maven - War file . Some plugins in maven will do that but they are including source files in classes folder. But my requirement is that when I import the same war file again into eclipse I should be able to work on that war like any other normal war.
Basically I should be able to work on the same war after importing it to eclipse when I build maven project. (I'm using maven3. )
I remember that's not trivial because the war-plugin doesn't support the handy includes-configuration-element you know from the jar-plugin by default.
Therefore I suggest you to use the maven-assembly-plugin to configure the inclusion of your sourcefiles. You only need to define an assembly descriptor, where you list includes and excludes of your war-package. Maybe you can reuse one of the predefinied assembly descriptors to save some time.
As part of my build process, I am generating a separate artifact (compressed file with static web files inside) in the which I would like to contain the same information that is in the manifest file generated by the war plugin. The manifest file is generated correctly into the war file, but I'd like access to it so I can copy it and put it in my compressed file as well.
In the documentation for the maven-war-plugin:manifest goal, it reads:
The manifest file is created in the warSourceDirectory.
Which defaults to the location: ${basedir}/src/main/webapp
However, the only manifest that is generated is within the war. It doesn't make sense to me either that the generated manifest file would be put into my source. I would think that it would be put in the target where the war is packaged from.
Am I missing something?
If you look at the built-in lifecycle reference you will see that at no point in the <packaging>war</packaging> lifecycle is the war:manifest goal bound to any phase.
Thus by default this goal will not execute (unless you add an execution).
If there is a MANIFEST.MF file at ${basedir}/src/main/webapp/META-INF/MANIFEST.MF then when the war:war goal is executing it will use that file rather than generating the MANIFEST.MF on the fly and embedding it straight into the .war file without creating an intermediary file.
From what I can tell, the war:manifest goal is designed to be used to generate a template MANIFEST.MF which you can then customise and use going forward.
The war plugin has a number of goals which I would tend to advise keeping clear of:
war:inplace
war:manifest
The reason is because both of these goals modify the files in your src tree which goes against the standard Maven practice of only touching files in target (which makes for a very nice mvn clean as you need only remove the target)
With regards to your question, the key thing is that you are generating a separate artifact. Maven works best when you stick to one artifact per Maven module. Thus the separate artifact will have a separate module. You just add the .war as a dependency (remember <type>war</type>) and then use dependency:unpack-dependencies to unpack the .war file... you can have it only unpack the META-INF/MANIFEST.MF and if that ends up as target/${project.build.finalName/META-INF/MANIFEST.MF then when you are packing up this second artifact you will ensure it has the same manifest as your .war file.