I'm trying to deploy a single war project to multiple tomcats using mvn tomcat:deploy. Since these are listener project (aka workers), their overlapping names are irrelevant.
When I have
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>tomcat-maven-plugin</artifactId>
<configuration>
<url>`http://192.168.116.54:8080/`manager/text</url>
<server>standaardTomcat</server>
<path>/picalcworker</path>
</configuration>
</plugin>
a single war will be deployed on that server. Though I cannot have multiple 'plugins' of the same groupId artifactId combination, so simply copy this and change the url will result in a warning and only one (the latest) to be deployed.
This plugin further seems to allow:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>tomcat-maven-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<id>1</id>
<phase>deploy</phase>
<goals>
<goal>deploy</goal>
</goals>
<configuration>
<url>http://192.168.116.52:8080/manager/text</url>
<server>standaardTomcat</server>
<path>/picalcworker</path>
</configuration>
</execution>
<execution>
<id>2</id>
<phase>deploy</phase>
<goals>
<goal>deploy</goal>
</goals>
<configuration>
<url>http://192.168.116.53:8080/manager/text</url>
<server>standaardTomcat</server>
<path>/picalcworker</path>
</configuration>
</execution>
</executions>
</plugin>
but then mvn tomcat:deploy will try to deploy to localhost, since <configuration><url> was empty in this plugin's root (but I cannot supply a singular url there, since I need multiple). Also possible tomcat7 and tomcat6.
I really like the deploy and undeploy options. Does anybody know how to make this work, or some reasonable alternative?
currently not possible.
Note the plugin is now hosted at Apache see http://tomcat.apache.org/maven-plugin.html .
Can you load a jira for that ? That need a bit of code (maybe you can add a patch :-) )
Related
When using the maven-release-plugin to release an artifact onto a repository, the entire pom is copied. This includes sections build and reporting.
I can understand that deployement information is propagated since dependencies of a project by the same creators are likely to be deployed on the same servers, but, for non-pom artifact, I don't understand the point of having the build information.
Is it possible to create a release stripped of this information?
Use the flatten-maven-plugin
https://www.mojohaus.org/flatten-maven-plugin/
I copied the relevant plugin configuration from the website above.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>flatten-maven-plugin</artifactId>
<!--<version>1.1.0</version>-->
<configuration>
</configuration>
<executions>
<!-- enable flattening -->
<execution>
<id>flatten</id>
<phase>process-resources</phase>
<goals>
<goal>flatten</goal>
</goals>
</execution>
<!-- ensure proper cleanup -->
<execution>
<id>flatten.clean</id>
<phase>clean</phase>
<goals>
<goal>clean</goal>
</goals>
</execution>
</executions>
</plugin>
I strips the POM from all unnecessary information.
I have a webjars project that I'd like to build snapshots and have them deployed locally (within our infrastructure) but have the releases be managed by webjars.org.
https://github.com/webjars/oscar/blob/15.0.0-RC1/pom.xml
The problem I'm facing is that they need the nexus-staging-maven-plugin defined as part of their release process. So I'd like to keep the POM tailored for them as much as possible, and just make our own deviations via command line (or worst case, profile) if possible.
Typically, if doing this from scratch, you'd probably introduce the staging plugin in a profile, but I don't think I have that option. (I might have to make the modification though and discuss it with them.)
I've never used the staging plugin before, so this is my first exposure and it isn't a pleasant one given what I'm trying to do. I feel like I'm fighting the system.
I thought I had something by specifying:
-DsonatypeOssDistMgmtSnapshotsUrl=http://myurl
and that pushes the artifact at the correct location, but then I can't figure out how to supply credentials. (401 unauthorized) I thought specifying the serverId might work, but no.
-DserverId=public-snapshots
http://books.sonatype.com/nexus-book/reference/staging-deployment.html
I then tried creating a profile, where I'd do something like this:
<profile>
<id>disable-staging</id>
<build>
<plugins>
<plugin>
<groupId>org.sonatype.plugins</groupId>
<artifactId>nexus-staging-maven-plugin</artifactId>
<version>1.6.5</version>
<configuration combine.self="override">
<executions>
<execution>
<id>injected-nexus-deploy</id>
<phase>none</phase>
</execution>
</executions>
</configuration>
</plugin>
</plugins>
</build>
</profile>
but that doesn't help. The effective-pom shows this:
<plugin>
<groupId>org.sonatype.plugins</groupId>
<artifactId>nexus-staging-maven-plugin</artifactId>
<version>1.6.5</version>
<extensions>true</extensions>
<executions>
<execution>
<id>injected-nexus-deploy</id>
<phase>deploy</phase>
<goals>
<goal>deploy</goal>
</goals>
<configuration combine.self="override">
<executions>
<execution>
<id>injected-nexus-deploy</id>
<phase>none</phase>
</execution>
</executions>
</configuration>
</execution>
</executions>
<configuration combine.self="override">
<executions>
<execution>
<id>injected-nexus-deploy</id>
<phase>none</phase>
</execution>
</executions>
</configuration>
</plugin>
and I can't unbind the deploy phase.
I'm wondering if anyone has any ideas on what to do in this type of scenario?
You can use the Nexus Staging Plugin's property skipNexusStagingDeployMojo to achieve this:
mvn clean package deploy:deploy -DskipNexusStagingDeployMojo=true
-DaltDeploymentRepository=snapshots::default::https://my.nexus.host/content/repositories/snapshots-local
It is important to explicitly invoke package and then deploy:deploy, as otherwise (when only invoking mvn deploy) the default execution of the maven-deploy-plugin is suppressed by the Nexus Staging Plugin (even with the skip set to true).
Dealing with a legacy project, I have the need to load text resources from a jar at an URL.
The text resources will be then filtered and included in the output; those resources come from a released artifact.
From resource-plugin I see it is only possible to give a number of directories; would it be possible to load resources as I need?
I want to do somthing like this, but using a remote jar instead of the oher project in the workspace:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<executions>
<execution>
<id>copy-resources</id>
<phase>process-resources</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/${project.build.finalName}</outputDirectory>
<resources>
<resource>
<directory>../<another project on the same workspace>/src/main/filtered-resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
Remote resource plugin, as suggested in one of the answer doesn't work because no file from the imported bundle ends up in target; there is no way I can produce the original bundle using remote resource plugin (it's a legacy projetc still in use and completely out of my control).
I think the Maven Remote Resources Plugin will suit your needs.
EDIT:
Snippet obtained from the usage page of the plugin. That XML fragment will attach the plugin to the generate-sources phase (choose a different one if it doesn't fit your needs), will download the apache-jar-resource-bundle artifact and uncompress its contents into ${project.build.directory}/maven-shared-archive-resources.
For better results is recommended that the resources artifact had been created using the bundle goal of the same plugin.
<!-- Turn this into a lifecycle -->
<plugin>
<artifactId>maven-remote-resources-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>process-remote-resources</id>
<phase>generate-sources</phase>
<goals>
<goal>process</goal>
</goals>
<configuration>
<resourceBundles>
<resourceBundle>org.apache:apache-jar-resource-bundle:1.0</resourceBundle>
</resourceBundles>
</configuration>
</execution>
</executions>
</plugin>
EDIT 2: Alternative Solution using AntRun
If your artifacts don't suit Maven needs and you need something more customized, then using AntRun plugin you could get it somehow:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<id>download-remote-resources</id>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<get src="URL of the resource" dest="${project.build.directory}" />
<unzip src="${project.build.directory}/filename.[jar|zip|war]" dest="${project.build.directory}/${project.build.finalName}" />
</target>
</configuration>
</execution>
</executions>
</plugin>
I'm pretty new to Maven...
What I'm trying to do is skip the maven-deploy-plugin during the deploy phase, while replacing it with my own plugin (i.e. I'm deploying to a non-repository location).
I realize I could do this in multiple other ways, but the boss wants to be able to run:
mvn deploy
To get the results of my current workaround, which is disabling the maven-deploy-plugin (which seems to be disabling the entire deploy phase), and manually specifying the custom upload goal from the command line.
I'm currently failing to succeed in my mission with:
<executions>
<execution>
<phase>deploy</phase>
</execution>
</executions>
in the build/plugins/plugin section containing my plugin specification, since the deploy phase is skipped by:
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.7</version>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
Thanks!
disabling the maven-deploy-plugin (which seems to be disabling the entire deploy phase)
This is not correct. Disabling maven-deploy-plugin doesn't disable the entire deploy phase. This is how it should be done (looks like you're doing it already):
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
Try this (untested) alternative for disabling the standard deploy plugin:
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.7</version>
<executions>
<execution>
<id>default-deploy</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
I want to build on #yegor256's answer a bit... 8 years, 4 months later!
I found myself here getting into the weeds on some legacy Maven configurations that were full of cruft. Coming from a Maven mindset, albeit some years between now and active hacking, I was re-familiarizing myself with the Maven lifecycle.
TLDR... mvn help:effective-pom is your friend. Use your IDE's tools for viewing the effective POM often (NetBeans makes it easy. I added a keyboard shortcut in IntelliJ.)
In the configuration I was reviewing, the previous developers had created two (2) deploy-file executions, one war, one jar.
<build>
...
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.8.2</version>
<executions>
<execution>
<id>deploy-war</id>
<phase>deploy</phase>
<goals>
<goal>deploy-file</goal>
</goals>
<configuration>
... omitted ...
</configuration>
</execution>
<execution>
<id>deploy-jar</id>
<phase>deploy</phase>
<goals>
<goal>deploy-file</goal>
</goals>
<configuration>
... omitted ...
</configuration>
</execution>
</executions>
</plugin>
...
</plugins>
...
</build>
I was aware that these executions would be appended to the default-deploy bound to the deploy phase and observed this behavior in the logs. The default-deploy would run, uploading an empty war file, then the deploy-war would run, uploading, and overwriting, the first war file.
Several options exist.
skip and combine.self="override" (my preference)
As presented, using <skip> as a <configuration> option is viable. It is safe and more portable than setting setting the <phase> to none.
However, it will be inherited by the other executions (certainly as presented). To prevent this, you must explicitly tell your additional <execution> configurations to not inherit.
...
...
<executions>
<execution>
<id>deploy-war</id>
<phase>deploy</phase>
<goals>
<goal>deploy-file</goal>
</goals>
<configuration combine.self="override">
... omitted ...
</configuration>
</execution>
...
...
Override default-deploy
Another option, possibly more verbose and lest esoteric than combine.self="override" is to override the execution of the default-deploy <id> of the plugin.
...
<execution>
<id>default-deploy</id>
<configuration>
<skip>true</skip>
</configuration>
</execution>
...
This will not be inherited by the additional <executions>.
Another option
As #yegor256 notes, but in the additional configurations explicitly state <skip>false</skip> to "reset" the inherited <skip> from the plugin.
HTH.
We're using non-public artifacts from third-party companies in our project. We don't have maven proxy installed (and there're no plants to do so, because we found it complicates things rather than solves problems. especially if no internet connection or VPN is available).
So I created set of 'maven install file' plugin executions, like this:
<plugin>
<artifactId>maven-install-plugin</artifactId>
<version>2.3.1</version>
<inherited>false</inherited>
<executions>
<execution>
<id>install-artifacts.1</id>
<goals>
<goal>install-file</goal>
</goals>
<phase>initialize</phase>
<configuration>
<pomFile>thirdparty/gwt-0.99.1.pom</pomFile>
<file>thirdparty/gwt-0.99.1.jar</file>
</configuration>
</execution>
<execution>
<id>install-artifacts.2</id>
<goals>
<goal>install-file</goal>
</goals>
<phase>initialize</phase>
<configuration>
<pomFile>thirdparty/morphia-0.99.1.pom</pomFile>
<file>thirdparty/morphia-0.99.1.jar</file>
</configuration>
</execution>
<execution>
<id>install-artifacts.3</id>
<goals>
<goal>install-file</goal>
</goals>
<phase>initialize</phase>
<configuration>
<pomFile>thirdparty/gwt-oauth2-0.2-alpha.pom</pomFile>
<file>thirdparty/gwt-oauth2-0.2-alpha.jar</file>
</configuration>
</execution>
</executions>
</plugin>
it works great and does exactly what we need. However if new artifact is added - new big XML section has to be added.
Is there any way to avoid this, like use 'yet another plugin' which will search for folder and install everything from it?
Best solution for such kind of thing is to install a repository manager.
You've written you won't installing a proxy but that's the wrong way. The only solution to solve such kind of problems is to install a repository manager.