I am using the jboss-as-maven-plugin from redhat.
I have a standalone JBoss Server with port offset 100 and want to use a property with this value. But if I use the following configuration, the plugin uses the default port 9999
JBAS012144: Could not connect to remote://localhost:9999
<plugin>
<groupId>org.jboss.as.plugins</groupId>
<artifactId>jboss-as-maven-plugin</artifactId>
<version>7.7.Final</version>
<configuration>
<port>${jboss.port}</port>
</configuration>
</plugin>
<properties>
<jboss.port>10099</jboss.port>
</properties>
I know I can start the deployment with -Djboss-as.port=10099 but i prefer the property.
It would be really nice, to set the properties in an extra file.
So I took the properties-maven-plugin to read a user.properties file with the properties jboss.host and jboss.port.
This plugin is invoked by the initialized Phase
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<executions>
<execution>
<id>read-properties</id>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>${project.basedir}\user.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
I can read and use the properties from the file in the whole lifecycle, but when I call jboss-as:deploy, the properties are empty
and the Plugin took the default values. The JBoss Plugin sais: Invokes the execution of the lifecycle phase package prior to executing itself.
Related
I need to set a property for evosuite through maven. The property is assertion_strategy and I want to set it to all
I tried to pass it through the maven commandm didn't work.
I also tried to set it through the pom, but I guess I'm not using the right tags
<plugin>
<artifactId>evosuite-maven-plugin</artifactId>
<groupId>org.evosuite.plugins</groupId>
<version>${evosuiteVersion}</version>
<configuration>
<properties>
<property>
<name>assertion_strategy</name>
<value>all</value>
</property>
</properties>
</configuration>
<executions>
<execution>
<goals>
<goal>prepare</goal>
</goals>
<phase>process-test-classes</phase>
</execution>
</executions>
</plugin>
I expect to see -Dassertion_strategy=all when I'm looking at the evosuite jar execution within the maven debug mode command.
Thanks
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 :-) )
The question is how can I use different properties files for integration testing. Detailed explanation follows.
I'm trying to do in container integration tests with Maven, using tomcat7-maven-plugin. The project uses Spring and JPA. At present what I've figured out is the following:
Unit test class names follow the pattern *Test and run with mvn test by maven-surefire-plugin
Integration test class names follow the pattern *IT and run with mvn verify by maven-failsafe-plugin
With executions I can trigger to start and stop tomcat and deploy the war file
All of this works and when I run mvn verify Tomcat is started.
However instead of using a regular database, I would like to use an in memory database. My database configuration is defined in the file src/main/resources/META-INF/spring/database.properties loaded through context:property-placeholder.
I tried to define an alternative file in src/test/resources/META-INF/spring/database.properties, but is ignored. I know that is possible to define system properties within tomcat7-maven-plugin, but I don't know how to use them to trigger loading of different properties files.
My tomcat7-maven-plugin configuration is the following:
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.1</version>
<configuration>
<port>9090</port>
<path>/processing</path>
<useTestClasspath>true</useTestClasspath>
<systemProperties>
<example.value.1>alpha</example.value.1>
</systemProperties>
</configuration>
<executions>
<execution>
<id>start-tomcat</id>
<phase>pre-integration-test</phase>
<goals>
<goal>run-war-only</goal>
</goals>
<configuration>
<fork>true</fork>
</configuration>
</execution>
<execution>
<id>stop-tomcat</id>
<phase>post-integration-test</phase>
<goals>
<goal>shutdown</goal>
</goals>
</execution>
</executions>
</plugin>
Properties are loaded by context-main.xml with the following line:
<context:property-placeholder location="classpath*:META-INF/spring/*.properties"/>
I load context configuration from web.xml with the following:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath*:META-INF/spring/context-*.xml</param-value>
</context-param>
Any suggestion on how to load alternative properties file for testing?
One way to do it, is with Maven profiles and the ant plugin. I suspect that is not the most elegant way, and I'm open to listen for better solution, but for now it solves my problem.
A profile is a way to have a different Maven configuration depending on command line arguments, so in my case to run the integration tests, I run the command mvn -Pintegration clean verify. Here integration is the name of the profile, and is defined in pom.xml, after the properties as follows:
<profiles>
<profile>
<id>standard</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
<profile>
<id>integration</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<phase>test</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>Copying test database.properties to ${project.build.outputDirectory}/META-INF/spring/</echo>
<copy file="src/test/resources/META-INF/spring/database.properties"
todir="${project.build.outputDirectory}/META-INF/spring/" verbose="true" overwrite="true" />
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
Using mvn clean package will instead use the standard profile. It's interesting to mention that profiles can also be defined outside the pom, in .m2/settings.xml
See also: Building For Different Environments with Maven 2 -- Notice that the overwrite parameter in the copy is essential or it will work only at random, and is not mentioned in the linked document.
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.
In my project, we've created a Maven module to get the specific JBoss AS and unpacked.
Then all the test cases can be run under this Jboss AS as embedded container.
We're using jboss-ejb3-embedded-standalone to call the embedded container, however, it just find the JBOSS_HOME from environment variables and use that one to run.
Thus we have to update the JBOSS_HOME per mvn install.
I tried to do this in maven by introduce exec-maven-plugin as below:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version>
<configuration>
<executable>env</executable>
<environmentVariables>
<JBOSS_HOME>
C:/Sample/embedded-container/jboss-${version.org.jboss.jbossas}
</JBOSS_HOME>
</environmentVariables>
</configuration>
<executions>
<execution>
<id>resetJbossHome</id>
<phase>integration-test</phase>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
</plugin>
In the output of console, I can see
[INFO] --- exec-maven-plugin:1.2.1:exec (resetJbossHome) # test-embedded ---
....
JBOSS_HOME=C:/Sample/embedded-container/jboss-6.1.0.Final
....
But when launching JBOSS, it's still running the one with origin JBOSS_HOME set.
Besides, I've tried using maven-antrun-plugin too.
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>copyRelease</id>
<phase>pre-integration-test</phase>
<configuration>
<tasks>
<exec executable="env">
<env key="JBOSS_HOME" value="C:/Sample/embedded-container/jboss-${version.org.jboss.jbossas}"/>
</exec>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
It turns out the same.
Am I wrong on the configuration or there're some better way?
Take a look at the Maven profiles.
You can define one profile for testing, one for production, with different properties, such as
<profiles>
<profile>
<id>test</id>
<jboss.home>PATH TO JBOSS TEST INSTANCE</jboss.home>
</profile>
<profile>
<id>prod</id>
<jboss.home>PATH TO JBOSS PROD INSTANCE</jboss.home>
</profile>
</profiles>
And in your exec plugin :
<environmentVariables>
<JBOSS_HOME>
${jboss.home}
</JBOSS_HOME>
</environmentVariables>