March 2008 Archives
Together with my collegue Serge Pagop i hereby announce the foundation of the JBoss User Group Munich (JBUGM). Further details can be found on the corresponding web page
http://www.jbug-munich.org
The first meeting is already scheduled for the 31st March 2008 with an exciting presentation of the JBoss/Seam expert speaker Francis Pouatcha (technical lead at ADORSYS Ltd.). He will present a hot topic from JBossWorld Orlando 2008 entitled "EJB3, SEAM, JSF and RichFaces on JBoss 4.2.0". We are looking forward to welcome anybody who is interested to join us for an informative and enjoyable evening.
See you there...
http://www.jbug-munich.org
The first meeting is already scheduled for the 31st March 2008 with an exciting presentation of the JBoss/Seam expert speaker Francis Pouatcha (technical lead at ADORSYS Ltd.). He will present a hot topic from JBossWorld Orlando 2008 entitled "EJB3, SEAM, JSF and RichFaces on JBoss 4.2.0". We are looking forward to welcome anybody who is interested to join us for an informative and enjoyable evening.
See you there...
Profiles are Maven's way of supporting different runtime configurations in the build lifecycle. They can be activated in several different ways e.g. by a particular value of a system property. While you can trigger a profile by setting the respective system property in the mvn commandline e.g.
As you can imagine in a multi module project this fact can get extremely annoying: you execute multiple goals and always have to specify the same property again and again. Potentially you destroy the whole project state if you accidentally forget to provide it.
Fortunately there is a simple yet effective way to help you out of this situation: adding the required property to the MAVEN_OPTS environment variable. It's that easy...
mvn install -Dappserver=jboss
it is n o t possible to use a maven property defined inside the pom. That's not allowed because pom defined properties can themselves be changed inside a profile.As you can imagine in a multi module project this fact can get extremely annoying: you execute multiple goals and always have to specify the same property again and again. Potentially you destroy the whole project state if you accidentally forget to provide it.
Fortunately there is a simple yet effective way to help you out of this situation: adding the required property to the MAVEN_OPTS environment variable. It's that easy...
If you implement Maven projects that are used and build by several other people it's mostly advisable to validate the reqired environment conditions on the build machine. How nice that Apache provides the Maven-Enforcer-Plugin that allows controlling constraints like the Maven/ JDK versions, the OS version or the existence or value sets of environmental variables.
The Maven-Enforcer-Plugin is called by default during the validate phase of Maven's build lifecycle and lets you define a set of rules that are to be checked.
Here is an example configuration to be placed in your pom.xml:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<!-- Allow any Java >= 1.5, but not 1.6 or above -->
<requireJavaVersion>
<version>[1.5,1.6)</version>
</requireJavaVersion>
<!-- Allow any Maven >= 2.0.5 -->
<requireMavenVersion>
<version>[2.0.5,)</version>
</requireMavenVersion>
<!-- Check existence and value of system property -->
<requireProperty>
<property>appserver.name</property>
<message>System property 'appserver.name' is not set!</message>
<regex>glassfish|jboss</regex>
<regexMessage>jboss and glassfish are supported!</regexMessage>
</requireProperty>
</rules>
</configuration>
</execution>
</executions>
</plugin>
Continue reading Maven Enforcer Plugin.