How to specify my own manifest file in the Gradle war plugin? I need a one to one translation of the below maven pom snippets to Gradle.
I wish there is a one to one translation tool from maven to grade. btw, the gradle init does not address the details such as exlcude, manifestFile.
from maven pom.xml:
<build>
<defaultGoal>validate</defaultGoal>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<failOnMissingWebXml>false</failOnMissingWebXml>
<archiveClasses>true</archiveClasses>
<warSourceExcludes>WEB-INF/classes/**</warSourceExcludes>
<archive>
<manifestFile>src/main/webapp/META-INF/MANIFEST.MF</manifestFile>
</archive>
</configuration>
</plugin>
</plugins>
</build>
See official documentation : you can customize the Jar/war manifest as follows (more details in the Manifest API )
war{
manifest {
// include attributes from a custom manifest file
from("src/main/resources/CUSTOM-MANIFEST.MF")
// specify custom attributes
attributes('My-Attribute': 'value')
}
}
Note that Gradle will merge your custom attributes with the ones generated by the war task itself, if any.
Related
I don't want to include external jars when I build a war.What should I do?
Though not sure about why are you thinking to exclude the jar files, but yes you can do that if you are using maven-war-plugin
This will work out
<build>
<plugins>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.6</version>
<configuration>
<packagingExcludes>WEB-INF/lib/*.jar</packagingExcludes>
</configuration>
</plugin>
</plugins>
</build>
This a whole bunch of configuration plugin that excludes all .jar files.
This source explains about that and even regex patterns that can be used.
I need to be able to allow my maven package to be executed in two contexts.
User needs to execute jar from the command line to generate a licence key from an AWT dialog that appears when the user executes java -jar myjar.jar
myjar needs to also download all its transitive dependencies (in the "normal" maven way) when a client project references myjar as a dependency.
Scenario 1 requires the AWT forms jar to be packaged so that the AWT dialog pops up.
Scenario 2 requires all the other dependencies to be downloaded as the client project builds.
How do I package this to keep it as small as possible?
I've tried the jar-plugin, the shade-plugin and the assembly-plugin independently without much luck.
JAR-PLUGIN:
Placing the forms-1.2.1.jar in the lib/ directory and adding it to the classpath doesn't work because java -jar myjar.jar will not load it at the commandline
SHADE-PLUGIN:
Downloads the internet. How to exclude some dependencies?
ASSEMBLY-PLUGIN:
Downloads the internet. How to exclude some dependencies?
Is there a way to package the transitive dependencies of forms-1.2.1.jar (for scenario 1) but exclude all other dependencies at packaging time so they are downloaded at client project build time (for scenario 2).
Can the jar-plugin or assembly-plugin do this?
What you think about the following:
<project>
[...]
<build>
[...]
<plugins>
<plugin>
<!-- NOTE: We don't need a groupId specification because the group is
org.apache.maven.plugins ...which is assumed by default.
-->
<artifactId>maven-assembly-plugin</artifactId>
<version>2.5.2</version>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
[...]
</project>
That will produce a jar file which contains all dependencies and make it possible to call it from command line, but to get it working correctly you need a supplemental part:
<project>
[...]
<build>
[...]
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.5.2</version>
<configuration>
[...]
<archive>
<manifest>
<mainClass>org.sample.App</mainClass>
</manifest>
</archive>
</configuration>
[...]
</plugin>
[...]
</project>
I am following this Contract first using CXF tutorial and while the resulting pom.xml generates sources and even completes build successfully, it fails to create a WAR file.
Instead, it creates a JAR file.
My understanding is that the part in the pom.xml that's responsible for creating the WAR is:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<outputDirectory>D:/path/to/profile/autodeploy</outputDirectory>
</configuration>
</plugin>
I don't see any <goal> or <execution> element there (unlike in the build-helper-maven-plugin one), but I also understand that with this plugin this is implied as even the official usage page demonstrates:
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
<webappDirectory>/sample/servlet/container/deploy/directory</webappDirectory>
</configuration>
</plugin>
</plugins>
</build>
...
</project>
So... what am I missing?
What could possibly explain a maven-war-plugin that behaves in unexpected way like this and produces a JAR instead of a WAR by default?
Is there a way to force it to produce a WAR?
packaging should be as below.
<packaging>war</packaging>
if it won't help then try binding your plug-in configuration with a lifecycle phase.
in your project definition , please check if packaging is missing or not , it should be some thing like this .
<groupId>some.groupid</groupId>
<artifactId>My Web Application</artifactId>
<version>0.0.1</version>
<packaging>war</packaging>
<description>My First Web Application</description>
By default maven war plugin binds to package phase of the lifecycle ,so its important that we should mention the type of packaging we want once the build is done.
I would like to suggest to have a look at the Maven specs for war plugin.
I using Maven 3 + hudson + artifacotory
I used the following
<artifactId>maven-war-plugin</artifactId> <addClasspath>true</addClasspath> <classpathPrefix>WEB-INF/lib/</classpathPrefix> </manifest>
and I got the result as.....
WEB-INF/lib/gwt-servlet-2.4.0.jar WEB-INF/lib/gwt-user-2.4
.0.jar WEB-INF/lib/validation-api-1.0.0.GA.jar WEB-INF/lib/validation
-api-1.0.0.GA-sources.jar WEB-INF/lib/log4j-1.2.16.jar WEB-INF/lib/co
mmons-lang-2.6.jar
I am find well and good.
My one more requirement is,
I need to add/append two more libs with the above manifest file. see below
/u01/app/TimesTen/tt1121/lib/orai18n.jar /u01/app/TimesTen/tt1121/lib/ttjdbc5.jar
So how can add/append this is to my Manifest, so that above 3 will be included?
maven war plugin as well as maven jar plugin use maven archiver which in turn allows you to specify your own manifest file. According to the documentation,
The content of your own manifest file will be merged with the entries
generated by Maven Archiver.
Cut/pasting the relevant pom snippet from the above link for ready reference
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
...
<configuration>
<archive>
<manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile>
</archive>
</configuration>
...
</plugin>
</plugins>
</build>
...
</project>
So you could add the additional entries in this custom MANIFEST.MF and use it in conjunction with the maven war plugin.
I am currently struggling with Maven: I have a complex project made of several nested modules and for some of those modules, I have similar configurations in the POMs.
I would like to make it clean. Actually, I would like to define a "runnable-jar" common configuration and activate it in some modules.
Here is the POM fragment I would like to share between several projects:
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<!-- Use a custom descriptor, with suffix "bin" -->
<descriptors>
<descriptor>src/main/assembly/runnable-jar-assembly.xml</descriptor>
</descriptors>
<!-- Add main class to manifest -->
<archive>
<manifest>
<mainClass>${mainClass}</mainClass>
</manifest>
</archive>
</configuration>
<!-- Add build of this package to lifecycle -->
<executions>
<execution>
<id>make-runnable-jar</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
In some of the POMS, I would like to be able to do something like:
<!-- Set the main class -->
<properties>
<mainClass>my.main.Class</mainClass>
</properties>
<!-- Activate runnable jar build -->
<import>src/main/pom/runnable-jar-pom.xml</import>
I have searched for a mean to import some XML fragments into a POM, or to define a whole XML nodeset macro.
For what I have found, the closest solution would be to define a profile in the parent POM and activate it in some sub modules by testing the presence of a file. See this related question. But I am facing the problem of the {basedir} property not being set correctly inherited / set.
I find it very surprising to need a hack to do something so basic (=usual). How do you usually handle this in Maven ?
I have just discovered something that might solve my problem :
A module does not require to be a sub-module of its parent module.
Parent and sub-module relationships are separate concepts.
You can specify a parent POM module that is not the actual parent folder in your folder structure, by using the relativePath attribute (as explained in the doc)
In my case, I use the following layout:
main-project
utils (parent:main-project)
cli-programs (parent:main-project)
generic-cli (parent:cli-programs; Dummy & empty POM module)
cli-1 (parent:generic-cli)
cli-2 (parent:generic-cli)
Then, in generic-cli/pom.xml I can declare a configuration that is common to all my cli programs (like custom test suites, runnable-jar packaging, etc).
One way to do this would be to declare your <plugin> code inside <pluginManagement> of the parent pom of your multi-module project. The individual modules can then have a <plugin> section which can use this without redeclaring the contents.
Parent pom:
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
... all the details...
</plugin>
...
</plugins>
</pluginManagement>
Child poms:
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
</plugin>
</plugin>
Maven-tiles solves this. It's also on the roadmap for maven 3.x, tracked here.
not a total answer but a solution to the basedir problem is to use a common layout of the modules, e.g. root/modules/moduleA root/modules/moduleB.
You can't build the modules formm their own directory anymore, only through thr parent project. But you can work with the profiles.