I my CI setup I have deploy the zip file from nexus to tomcat server.
Below is my Deployment POM.
<execution>
<id>unpack</id>
<phase>install</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>//</groupId>
<artifactId>//</artifactId>
<version>//version</version>
<classifier>bin</classifier>
<type>zip</type>
<overWrite>true</overWrite>
<outputDirectory>//tomcat folder </outputDirectory>
<includes>**/*.war,appconf/dev/*.properties</includes>
</artifactItem>
</artifactItems>
<includes>**/*.properties</includes>
</configuration>
</execution>
i provided includes and property file under dev as below
<includes>**/*.war,test/dev/*.properties</includes>
So it creates a test folder and place the property files inside.I want to skip the dev folder but the property file has to copied and put directly inside the test fodler.
As of now the tomcat directory looks like test\dev\test.properties.
but I need to change test\test.properties when unpack the zip file.
help me to resolve this issue using MAVEN.
Related
We have an application.properties file in one project:
src
|--- main
|--- resources
|--- application.properties
It contains some Maven project property #variables# to initialise some properties such as:
info.app.branch=#branch.name#
As I understand through some experimentation and the above documentation, these are replaced by spring-boot-starter-parent, before it copies them over into target/classes/config.
In a dependent project, we explicitly copy the application.properties file over from the parent project's JAR using the Maven dependency plugin.
<artifactItem>
<groupId>...</groupId>
<artifactId>...</artifactId>
<outputDirectory>${project.build.directory}/classes</outputDirectory>
<includes>config/application.properties</includes>
</artifactItem>
As such, it's already in the target/classes/config directory, and no replacement of the #variables# takes place.
How can I ensure that Spring boot correctly replaces these variables?
Feels a bit awkward but you could probably specify the resource directory of the "dependent project" as the outputDirectory.
E.g:
<artifactItem>
<groupId>...</groupId>
<artifactId>...</artifactId>
<outputDirectory>${project.basedir}/src/main/resources</outputDirectory>
<includes>config/application.properties</includes>
</artifactItem>
This way I would expect the Spring Boot Maven plugin to treat them as regular properties of the project and properly replace the variables.
The way we solved this was to move the configuration files to a directory with a different name (we just called it 'configs'). The maven dependency plugin is then not unpacking directly into config:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>process-tools-resources</id>
<phase>process-resources</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>the-parent</groupId>
<artifactId>the-artifact</artifactId>
<outputDirectory>${project.build.directory}/classes</outputDirectory>
<includes>configs/application.properties</includes>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
We then use the Maven resources plugin to copy from configs into config, which is able to replace the #properties# for us:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
<execution>
<id>process-properties-placeholders</id>
<phase>process-resources</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<delimiters>
<delimiter>#</delimiter>
</delimiters>
<useDefaultDelimiters>false</useDefaultDelimiters>
<resources>
<resource>
<directory>${project.build.directory}/classes/configs</directory>
<filtering>true</filtering>
</resource>
</resources>
<outputDirectory>${project.build.directory}/classes/config</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
I am struggling to extract contents of nested zip file in an artifact.
Artifact has below content zipped:
Base_Config.zip
First_Pack.zip
01_first.json
02_second.json
Second_Pack.zip
01_third.json
02_fourth.json
able to extract only zip files under Base_config.zip not it's contents *.json
`<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.10</version>
<executions>
<execution>
<id>unpack</id>
<phase>prepare-package</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>com.shashank.bss.XXX</groupId>
<artifactId>testdatagen</artifactId>
<version>24.5.0</version>
<type>zip</type>
</artifactItem>
</artifactItems>
<outputDirectory>target/assemble/shashank/deps</outputDirectory>
<includes>testdatagen-*-First_Pack.zip</includes>
</configuration>
</execution>
`
Tried multiple solution:
Failed to get content using assembly descriptor,
Tried solution available on this as well:
Custom maven assembly
Not want to use deprecated plugin and the solution available there with plugin:
truezip-maven-plugin
Unpack inner zips in zip with Maven
Is it possible to get the work done by this plugin:
maven-dependency-plugin & unpack.
Or any other simple solution available from maven?
My users have been calling out for easily distributed native binaries with my library. I've got this working by distributing the natives in jars, which are extracted at runtime into a temporary directory.
However, the maven-native-plugin requires that the native is packaged as a jnilib (OS X), so (Linux) or dll (Windows). I have my own deploy target that packages a jar file and distributes that under the classifier natives. It's a bit annoying that this needs a special classifier.
How can I disable the deploy of the jnilib/so/dll?
How can I distribute my jar without any special classifier?
I do a similar thing, but I pack the native libraries inside zip files. After that, in the artifact that needs them, I pull and unpack the zip file with the maven dependency plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unzip</id>
<phase>prepare-package</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>foo</groupId>
<artifactId>bar</artifactId>
<version>1.0.0</version>
<type>zip</type>
<overWrite>true</overWrite>
<includes>**/*.dll</includes>
<outputDirectory>${project.build.directory}/natives</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
As you can see I don't use any classifiers.
I have a Maven project that builds a Swing client as a jar-with-dependencies.jar file. I want to use Java Web Start to distribute this my.gui-0.1.0-jar-with-dependencies.jar file. I've created a separate Maven project that builds a .war file with the JNLP artifacts for this purpose. I need to include the my.gui-0.1.0-jar-with-dependencies.jar in this .war file.
I haven't been able to determine the Maven coordinates for the jar-with-dependencies.jar file. If I use the Maven coordinates for the GUI project it puts the dependency .jar files for the GUI project in the WEB-INF/lib, which is not what I want. I need to have the my.gui-0.1.0-jar-with-dependencies.jar file itself in the .war file. (I suppose it could be in WEB-INF/lib.)
How do I tell Maven that the dependency is the jar-with-dependencies.jar file itself?
If there is another way besides the mechanism to tell Maven to include the jar-with-dependencies.jar itself that would work too. The jar-with-dependencies.jar has to be somewhere in the .war file I'm creating to support Java Web Start.
I know there is a Maven Webstart plugin, but that looks like a nightmare so I'm just building a .war file myself with the necessary JNLP artifacts.
Firstly, what you want is the JAR file to be available to be downloaded by users of the WAR file. Including the file in WEB-INF/lib as a standard dependency of the WAR project is not what you want. What you most likely want is the JAR to be put in a different directory in the WAR (such as /downloads).
To achieve this in Maven, you can use the Maven Dependency Plugin.
1: Use the dependency plugin to copy your JAR file to a temporary build directory.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<id>copy</id>
<phase>generate-resources</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>my.group</groupId>
<artifactId>myartifact</artifactId>
<version>1.0</version>
<type>jar</type>
<overWrite>false</overWrite>
<outputDirectory>${project.build.directory}/webapp-downloads</outputDirectory>
<destFileName>myartifact.jar</destFileName>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
here we are copying your JAR file to the ${project.build.directory/webapp-downloads directory
2: configure the WAR plugin to include the resources generated by the dependency plugin.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.2</version>
<configuration>
<webResources>
<resource>
<directory>${project.build.directory/webapp-downloads</directory>
<targetPath>downloads</targetPath>
</resource>
</webResources>
</configuration>
</plugin>
This will cause the JAR file to be bundled in you WAR under the downloads directory. Users can then download it by going to /downloads/myartifact.jar to download it.
In the case of webstart, you would configure your JNLP with the appropriate path instead of having the user directly download the JAR.
If you want to copy the .jnlp file too, like in my case, you could use the unpack goal. This works because the webstart-maven-plugin can pack the jars and the jnlp file into a zip.
<execution>
<id>unpack</id>
<phase>process-resources</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>myGroup</groupId>
<artifactId>myArtifact</artifactId>
<version>1.0</version>
<type>zip</type>
<overWrite>true</overWrite>
<outputDirectory>${project.build.directory}/webapp-downloads</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</execution>
What is the best way to put javascript/html/css code in the maven repository, so that is easily usable by java projects.
Is there a way to do it such that the included project can be easily made "web-visible" by the including project?
For example assume I write a very useful tricks.js file an put it in the mvn repository.
Is it possible to create a web project that adds tricks.js as a dependency and then doing
<script src="/some/thing/tricks.js"/>
causes the tricks.js file to be served?
External resources should be packaged into an artifact and published to the repository (for simplicity use a jar artifact, but you could specify an assembly to package a zip instead to make it clear what the artifact is for). The maven-dependency-plugin unpacks the jar's contents into a specified location in the war project. That folder is then specified as an external web resources directory for the maven-war-plugin.
The following configuration will unpack the contents of my-resources into the target/external-resources directory, then include the contents of that folder in the war as if they'd been defined in src/main/resources.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack</id>
<phase>generate-resources</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>name.seller.rich</groupId>
<artifactId>my-resources</artifactId>
<version>1.0.0</version>
<type>jar</type>
<overWrite>false</overWrite>
</artifactItem>
</artifactItems>
<outputDirectory>${project.build.directory}/external-resources</outputDirectory>
<overWriteReleases>false</overWriteReleases>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.0</version>
<configuration>
<webResources>
<resource>
<directory>${project.build.directory}/external-resources</directory>
</resource>
</webResources>
</configuration>
</plugin>
You can pack it into jar and then unpack it by maven plugins.