JBossWS has been completely mavenized since the 3.0.2 release.
Download Maven
Each JBossWS developer will need to install Maven to be able to build JBossWS components.
Set Up Maven Environment Options
The following environment options must be set up:
- Unix users
# set Maven home MVN_HOME=/your/maven/absolute/path export MVN_HOME # add Maven scripts to path variable PATH=$MVN_HOME/bin:$PATH export PATH
- Windows users
REM set Maven home SET MVN_HOME=C:/your/maven/absolute/path REM add Maven scripts to path variable SET PATH=%MVN_HOME/bin%;%PATH%
Maven mvn command uses MVN_HOME for Maven installation to be used when specified.
Create or Update Maven Settings (JBoss Nexus Maven Repository)
Starting from JBossWS 3.3.0.CR2, the new JBoss Maven repository based on Nexus is being used. For this reason the settings.xml file needs to have references to other repositories:
<settings>
...
<profiles>
<!-- jboss repository profile -->
<profile>
<id>jboss.repository</id>
<activation>
<property>
<name>!jboss.repository.off</name>
</property>
</activation>
<repositories>
<repository>
<id>jboss-public-repository-group</id>
<name>JBoss Public Maven Repository Group</name>
<url>https://repository.jboss.org/nexus/content/groups/public/</url>
<layout>default</layout>
<releases>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</releases>
<snapshots>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</snapshots>
</repository>
<repository>
<id>jboss-deprecated-repository</id>
<name>JBoss Deprecated Maven Repository</name>
<url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url>
<layout>default</layout>
<releases>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</releases>
<snapshots>
<enabled>false</enabled>
<updatePolicy>never</updatePolicy>
</snapshots>
</repository>
<repository>
<id>maven2.java.net</id>
<name>Java.net Repository for Maven 2</name>
<url>http://download.java.net/maven/2/</url>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>jboss-public-repository-group</id>
<name>JBoss Public Maven Repository Group</name>
<url>https://repository.jboss.org/nexus/content/groups/public/</url>
<layout>default</layout>
<releases>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</releases>
<snapshots>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</snapshots>
</pluginRepository>
</pluginRepositories>
</profile>
...
</profiles>...
</settings>
For further information, take a look at the documentation here. In particular, if you're a developer with a jboss.org account, consider basing your settings.xml on the developer's configuration.
Create or Update Maven 2 Settings (legacy settings)
Create or update ~/.m2/settings.xml file and include the following pluginGroups and profiles into it:
<?xml version="1.0" encoding="UTF-8"?>
<settings>
<pluginGroups>
<pluginGroup>org.jboss.maven.plugins</pluginGroup>
</pluginGroups>
<profiles>
<!-- jboss repository profile -->
<profile>
<id>jboss.repository</id>
<activation>
<property>
<name>!jboss.repository.off</name>
</property>
</activation>
<repositories>
<repository>
<id>repository.jboss.org</id>
<url>http://repository.jboss.org/maven2</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<repository>
<id>snapshots.jboss.org</id>
<url>http://snapshots.jboss.org/maven2</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>repository.jboss.org</id>
<url>http://repository.jboss.org/maven2</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
<pluginRepository>
<id>snapshots.jboss.org</id>
<url>http://snapshots.jboss.org/maven2</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
</profile>
<!-- user profile -->
<profile>
<id>user-profile</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<jboss.local.repository>/opt/svn/jboss.local.repository</jboss.local.repository>
<jboss421.home>/opt/svn/jbossas/tags/JBoss_4_2_1_GA/build/output/jboss-4.2.1.GA</jboss421.home>
<jboss422.home>/opt/svn/jbossas/tags/JBoss_4_2_2_GA/build/output/jboss-4.2.2.GA</jboss422.home>
<jboss423.home>/opt/svn/jbossas/branches/Branch_4_2/build/output/jboss-4.2.3.GA</jboss423.home>
<jboss500.home>/opt/svn/jbossas/tags/JBoss_5_0_0_Beta4/build/output/jboss-5.0.0.Beta4</jboss500.home>
<jboss501.home>/opt/svn/jbossas/trunk/build/output/jboss-5.0.0.CR1</jboss501.home>
</properties>
</profile>
</profiles>
</settings>
We defined two JBoss repository profile and user-profile profiles.
The first one will be used to download Maven2 artifacts from JBoss repositories.
The second one will be used to customize properties that are JBossWS user specific.
The JBoss repository profile is also documented here.
Note
Be careful to specify correct jboss.local.repository and jbossXYZ.home properties. Each developer can store its data in different locations.
Building JBossWS Components
If user wants to compile JBossWS components from sources, he just types the standard Maven command in a given JBossWS component source directory:
mvn package
Releasing JBossWS Components
Releasing a JBossWS component to the local repository is just a matter of typing the standard Maven command again:
mvn install
Using Maven Release Plugin
The Maven Release Plugin helps in saving time and preventing errors during the branching and tagging processes required at code freeze and release time. No more need to manually update project version in each module of multi-modules projects like the JBossWS stacks.
The plugin offers six goals that deal with different phases of the release. Here follows some suggestions on what could actually be useful here considering the JBossWS release procedure:
- release:branch: this can be used at code freeze to create the stack (and framework) QA branches. The suggested command is mvn release:branch -DbranchName=jbossws-branch-name -Djira.issue=JBWS-XYZ. This will branch the stack and move the trunk sources to the following (most likely snapshot) version. The specified jira.issue is used in the commit comment. The -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false options can be used to move the branch version forward and leave the trunk one unchanged.
- release:prepare: this can be used both to tag stack (and framework) QA branches and directly tag container integration, spi and common (where you might sometime want to skip the creation of branches). The suggested command are mvn release:clean followed by mvn release:prepare -Djira.issue=JBWS-XYZ. This will move the sources to the tag version, perform the tag and change the sources again to the next development version. The specified jira.issue is used in the commit comment. Please note that release:clean is required to make sure no resume from previous prepare is performed. Finally, once the release:prepare is done (thus the tag is created), you just need to manually delete the branch from svn.
Note
Verify all modules whose pom.xml has to be modified are actually included; when dealing with JBossWS stacks this means activating the testsuite profile (-Ptestsuite).
Note
Be careful when using the release plugin as it commits to svn. The -DdryRun=true option can be useful to have a preview of (some of) the changes performed by a given command.
Finally, due to a bug in Subversion starting from version 1.5.1, release:branch and release:prepare actually fail on first run when dealing with multi-modules projects (the JBossWS stacks for instance). The workaround is to run svn up after the failure (the error says a pom.xml already exists) and re-run the previous command (mvn release:branch -DbranchName=jbossws-branch-name -Djira.issue=JBWS-XYZ or mvn release:prepare -Djira.issue=JBWS-XYZ). This works completely fine for release:prepare as it resumes from the failed run (do not re-run release:clean). You need to fix the SCM tags on trunk after re-running release:branch instead, as they will erroneously point to the branch.
Comments