I would like to change the default HTTP port using the wildfly-maven-plugin to 8380. Usually, I can do that changing the offset, but this is not working, my changes are ignored and HTTP port continues on 8080.
I'm starting wildfly in the same maven project, because this is way more practical (download and start automatically). Just like that:
mvn wildfly:run -Dwildfly.version=10.1.0.Final
My project contains JAR, WAR and EAR. Classic structure.
As I understood from another SO questions, I need to put the plugin entry in each pom.xml that needs to be ignored, putting <skip>true</skip> in pom.xml of the: root, WAR and JAR. Just like that:
<plugin>
<groupId>org.wildfly.plugins</groupId>
<artifactId>wildfly-maven-plugin</artifactId>
<version>1.2.1.Final</version>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
If I not skip this guys, the Wildfly try to deploy the JAR/WAR/Root, what is not my objective. I would like to deploy only the EAR.
To do that, I use the <skip>false</skip> only for pom.xml of the EAR:
<plugin>
<groupId>org.wildfly.plugins</groupId>
<artifactId>wildfly-maven-plugin</artifactId>
<version>1.2.1.Final</version>
<configuration>
<skip>false</skip>
</configuration>
</plugin>
The localhost:8080/app/ works well after that.
But if I try to change the offset or http port, nothing different happens. This is some of the args that I already try on <configuration/> without success:
<server-args>
<server-arg>-Djboss.socket.binding.port-offset=300</server-arg>
</server-args>
<jvmArgs>-Djboss.socket.binding.port-offset=300</jvmArgs>
<jvmArgs>-Djboss.http.port=8380</jvmArgs>
The change that have some effect was:
<serverConfig>standalone.xml</serverConfig>
<server-args>
<server-arg>-Djboss.socket.binding.port-offset=300</server-arg>
</server-args>
<filename>${project.build.finalName}.ear</filename>
This also have changed the port (jvmArgs is deprecated):
<javaOpts>-Djboss.socket.binding.port-offset=300</javaOpts>
But in both cases the EAR application is not deployed...
Any idea? Thanks!
Finally, I found the solution.
The jvmArgs is deprecated. I used javaOpts:
<plugin>
<groupId>org.wildfly.plugins</groupId>
<artifactId>wildfly-maven-plugin</artifactId>
<version>1.2.1.Final</version>
<configuration>
<skip>false</skip>
<javaOpts>-Djboss.http.port=8380</javaOpts>
<filename>${project.build.finalName}.ear</filename>
</configuration>
</plugin>
Works!
You can use too:
<javaOpts>
<javaOpt>-agentlib:jdwp=transport=dt_socket,address=9087,server=y,suspend=n</javaOpt>
<javaOpt>-Djboss.http.port=8380</javaOpt>
</javaOpts>
To use more than one option for the JVM. In this example above I'm showing how to include a parameter to debug the Wildfly using the maven plugin.
But it's still a mistery why the EAR is not deployed when I use the offset configuration.
try not skipping the configuration :D
<plugin>
<groupId>org.wildfly.plugins</groupId>
<artifactId>wildfly-maven-plugin</artifactId>
<version>1.2.1.Final</version>
<configuration>
<port>8380</port>
</configuration>
</plugin>
Related
I am working in a project that uses a tomcat7-maven-plugin for testing, defined in the pom like this:
<build>
<plugins>
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<port>9092</port>
...
</configuration>
</plugin>
</plugins>
</build>
Is there a way to start this on a different port without editing the pom? When running mvn tomcat7:run -Dmaven.tomcat.port=9099 it still starts the tomcat on port 9092. I can't change the pom permanently due to others in the project desiring this default configuration, and I don't want to have to edit it locally every time I start the tomcat.
Thanks for help!
I have a project that consist of 3 different libraries. When I run install script it takes all libraries from repo and run mvn clean install on them. But this version of library already installed in repo. Is there a way to skip install phase if version in pom.xml equal version in my local repo.
I know that I can use local repo and just set dependencies. But my boss want that our project can build only with public repos and without any our repos.
You can bypass like this
-Dmaven.install.skip=true
<profiles>
<profile>
<id>skipInstall</id>
<activation>
<property>
<name>maven.install.skip</name>
<value>true</value>
</property>
</activation>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<executions>
<execution>
<id>default-install</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
</profile>
Last week Olivier Lamy patched this jira.
MINSTALL-73
Most maven plugins can be skipped by specifying something like:
<plugin>
<artifactId>maven-install-plugin</artifactId>
<version>X.Y</version>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
you can also set up build profiles to set properties and use that to determine the value. for example, running the command: mvn -Pexample would select the "example" profile. The POM would then contain:
...
<properties>
<skip.install>false</skip.install>
...
</properties>
...
<profile>
<id>example</id>
<properties>
<skip.install>false</skip.install>
</properties>
</profile>
...
<plugin>
<artifactId>maven-install-plugin</artifactId>
<version>X.Y</version>
<configuration>
<skip>${skip.install}</skip>
</configuration>
</plugin>
...
Using these POM additions, the default behavior for the install plugin will be to perform its default goal, but if the example profile is selected, then the install plugin will skip its goal.
Using what I learned from the other answers, this was the cleanest result for me.
In my super pom I added a pluginManagement/plugin to disable default-install and default-test phases when the property deployOnly is set.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.5.2</version>
<executions>
<execution>
<id>default-install</id>
<configuration>
<skip>${deployOnly}</skip>
</configuration>
</execution>
<execution>
<id>default-test</id>
<configuration>
<skip>${deployOnly}</skip>
</configuration>
</execution>
</executions>
</plugin>
So on the command line, I can disable install and test phases by adding -DdeployOnly.
mvn clean install #build and test everything
mvn deploy -DdeployOnly #just deploy it
I know that I can use local repo and just set dependencies. But my boss want that our project can build only with public repos and without any our repos.
Are you sure you understood correctly what you boss meant? I interpret the above as "don't install third party libraries in your local repository, use only libraries available in public repositories". This is different from "don't use your local repository" which is basically impossible, that's just not how maven works. I'd try to clarify this point.
Apart from that, I don't get the question which is very confusing (what repo are you talking about? What is the install script doing? Why do you call clean install on libraries? etc).
Extending the other answers, from the future.
Maven plugins have a surprisingly high freedom, how do they run. If they want, they can ignore/override the typical pom.xml settings. Furthermore, also the <configuration><skip>true</skip></configuration> is only a convention, nothing obligates a plugin to follow it, except that most of them is developed so.
My experiments with the recent problem show, that both #Cemo's and #MiloshBoroyevich solution should be utilized, also the plugin requires both to really let us in peace. More concretely, the only working configuration by me was this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.5.2</version>
<executions>
<execution>
<id>default-install</id>
<phase>none</phase>
</execution>
</executions>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
One of your options is to put the deployment to another module. I.e. have one pom.xml build the artifact and install it to the local repo, and another pom.xml to deploy it. This separation is quite common in larger projects, where the testsuite is sometimes a separate module or even a project, the packaging happens in several stages, etc.
- pom.xml - myProject-root - type=pom
- pom.xml - myProject-artifact - type=jar
- pom.xml - myProject-deploy - type=pom, does the deployment, skips it's own `install` goal
I try to build a web application based on multiple maven modules. One of the modules is called "web" and is solely responsible to package a war which should be deployed to a tomcat using the tomcat7-maven-plugin. I have following modules defined in my parent.pom:
common
persistence
persistence-embedded
service
rest
web
All of them are combined into one web-application-war, the web module has set packaging to war. The problem is, that my war file is deployed for each submodule (and the main-parent-module) over and over again when I run mvn tomcat7:redeploy, which leads to 7 deployments. Apparently, this is not how it should be. The tomcat7-maven-plugin configuration currently looks like this:
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<ignorePackaging>true</ignorePackaging>
<url>http://localhost:8080/manager/text</url>
<server>tomcatServer</server>
<path>/webapp</path>
<warFile> /home/username/dev/maven-multimodule-example/web/target/maven-multimodule-example-1.0-SNAPSHOT.war</warFile>
<username>admin</username>
<password>password</password>
</configuration>
</plugin>
As you can see, I need to specify the warFile (which is not a solution but rather a hack, because I can't use ${project.basedir} which would lead to the submodule-dir) to make it work.
However, if I run the web application with mvn tomcat7:run, it looks quite good, because the other non-war-building modules are skipped by the plugin.
How can I configure the plugin the right way to deploy the war file only once?
Every configuration within the <build> section of a parent POM will be inherited and thus executed in all child modules. So if you want to deploy only once, add it to only one POM (e.g. the web POM).
Thanks to dunni's help I noticed my missunderstanding of how multimodule projects are built. Now I've placed the plugin configuration in the web module and added an execution, bound to the install phase so that I can rebuild the whole project and get it deployed to my tomcat. Obviously maven takes care of the right execution order of the modules.
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<url>http://localhost:8080/manager/text</url>
<server>tomcatServer</server>
<path>/webapp</path>
<warFile>${project.basedir}/target/${project.parent.artifactId}-${project.parent.version}.war</warFile>
<username>admin</username>
<password>password</password>
</configuration>
<executions>
<execution>
<id>redeployafterinstall</id>
<phase>install</phase>
<goals>
<goal>redeploy</goal>
</goals>
</execution>
</executions>
</plugin>
I am developing a webapp running on Tomcat7, and using maven for dependencies/automated builds. Yesterday I started using the sass-maven-plugin, which is great. Its goal sass:update-stylesheets processes sass files and outputs css. Unfortunately, I can't have it executed during the webapp packaging. I am pretty new to maven too, so I might have missed something. Here's my understanding :
when I type mvn tomcat7:deploy, maven executes the deploy goal defined in the tomcat7 plugin
this plugin goes through some phases of the development lifecycle. More specifically, as mentioned in the doc, it "invokes the execution of the lifecycle phase package prior to executing itself."
if I map the goal sass:update-stylesheets to the package phase in <build><executions/></build>, it should be executed everytime I deploy/redeploy my app.
When I run mvn sass:update-stylesheets independently of tomcat7:deploy, everything is smooth. sass-maven-plugin gets the .scss files from src/main/resources, processes them and places the output in src/main/webapp/resources, where I want it to be to be deployed with my webapp. Unfortunately, if I don't run the command prior to tomcat7:deploy, I don't get any css for my pages. What did I get wrong? Also, is there any way I could map the sass:update-stylesheets to the phase process-resources, for instance, which would make more sense? Lastly, if this all works, will Eclipse's incremental build pick it up?
Here's my pom.xml (the relevant parts)
...
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
...
</configuration>
</plugin>
<!-- SASS processing -->
<plugin>
<groupId>org.jasig.maven</groupId>
<artifactId>sass-maven-plugin</artifactId>
<version>1.1.1</version>
<executions>
<execution>
<id>generate-css</id>
<phase>package</phase>
<goals>
<goal>update-stylesheets</goal>
</goals>
</execution>
</executions>
<configuration>
<useCompass>true</useCompass>
<resources>
<resource>
<source>
<directory>${basedir}/src/main/resources</directory>
</source>
<destination>${basedir}/src/main/webapp/resources</destination>
</resource>
</resources>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
Thanks in advance for your help.
You have configured the stuff in the plugin management section. Please move the execution and it's binding to the build section (that is, out of the pluginManagement's plugins section into build's plugins section).
I have this multi module project setup which uses Webstart and I need to bundle the WAR with SNAPSHOT JARs. When the JARs are bundled into the WAR, they are appended with a timestamp instead of the actual name. This is causing issues during their download.
Expected - ABC-1.0-SNAPSHOT.jar
Actual - ABC-1.0-20141002.211448-2.jar
Env:
OS: Unix
Maven: 3.2.1
JDK: 1.7
I have already tried useUniqueVersions=false by defining a maven-war-plugin and setting this in the manifest configuration.
My webstart config:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>webstart-maven-plugin</artifactId>
<version>1.0-beta-6</version>
<executions>
<execution>
<phase>process-resources</phase>
<goals>
<goal>jnlp-download-servlet</goal>
</goals>
</execution>
</executions>
<configuration>
<outputDirectoryName>.</outputDirectoryName>
<excludeTransitive>true</excludeTransitive>
<commonJarResources>
<jarResource>
...
</jarResource>
</commonJarResources>
<jnlpFiles>
<jnlpFile>
<templateFilename>JNLP-INF/APPLICATION_TEMPLATE.JNLP</templateFilename>
<outputFilename>client.jnlp</outputFilename>
<jarResources>
<jarResource>
...
</jarResource>
</jarResources>
</jnlpFile>
</jnlpFiles>
<sign>
...
</sign>
<outputJarVersions>false</outputJarVersions>
</configuration>
Appreciate any inputs.
UPDATE
Adding details about the WAR plugin I added
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
</plugin>
The behavior continues. I read that maven 3 uses a unique snapshot system. But I am trying to work my way around it.
Also tried the following without any luck
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
<outputFileNameMapping>${artifact.artifactId}-${artifact.baseVersion}.${artifact.extension}</outputFileNameMapping>
</configuration>
</plugin>
The creators of the maven-webstart-plugin have accidentally inverted the meaning of the flag useUniqueVersions. When set to true it produces jars of the form -SNAPSHOT.jar and when set to false (the default) it produces jars of the form --.jar
I found that setting the useUniqueVersions flag to true in the maven pom configuration produced my desired results.
I needed it like this because when deployed with the datestamp version of the snapshots when trying to launch it I was getting a "Resource not found" error when it tried to get the snapshot jar it was trying to launch. Presumably this means that the servlet code itself is not set up to handle the different naming on disk, despite the fact that the specific datestamp version number does end up in the jnlp itself.