Mule Studio and Maven Profiles

The maven project I’m working on has profiles for different environments, such as testing, development and deployment.

<profiles>
	<profile>
		<id>test</id>
		<activation>
			<activeByDefault>true</activeByDefault>
		</activation>
		<properties>
			<db.host>testdb.mycompany.com</db.host>
			<db.name>projectx</db.name>
		</properties>
	</profile>

	<profile>
		<id>development</id>
		<properties>
			<db.host>127.0.0.1</db.host>
		</properties>
	</profile>
</profiles>

To activate multiple profiles at run time, you use the command line option -P
mvn test -P test,development

Or inside eclipse with m2e, you can configure a list of active profiles under Run Configurations.

However, with Mule Studio, if you run the project as a Mule Application with Maven, there are no options to select maven profiles.

The way to get around this is to edit the maven profiles to be activated by a property or a file. In my case, I updated my pom.xml to

<profiles>
	<profile>
		<id>Test</id>
		<activation>
			<activeByDefault>true</activeByDefault>
			<property>
				<name>env</name>
				<value>test</value>
			</property>
		</activation>
		<properties>
			<db.host>testdb.mycompany.com</db.host>
			<db.name>projectx</db.name>
		</properties>
	</profile>

	<profile>
		<id>Development</id>
		<activation>
			<file>
				<exists>.git</exists>
			</file>
		</activation>
		<properties>
			<db.host>127.0.0.1</db.host>
		</properties>
	</profile>
</profiles>

The test profile is activated by setting the system property env to test. This is done in Mule Studio under Windows -> Preferences -> Mule Studio -> Maven Settings. In the “MAVEN_OPTS environment variable” text box, add -Denv=test. The development profile is activated by the existence of a .git file in the project root. Now when I run this as a mule+maven project in eclipse, the properties from both of these profiles are available.

You might ask wouldn’t it be easier to just add -P test,development to the MAVEN_OPTS text box? Yes it would definitely be, but mule studio complained about -P being an unrecognized option.

PS. I’m using mule studio 3.5.

Logging configuration in Jboss AS 7.1.1

My new work used Jboss Application Server 7.1 for its web applications. One of the things that surprised me was that it was not straightforward to configure webapps to use log4j.properties for logging configuration.

For development, I like to set all logging to ERROR level, except for the packages I’m working on. To achieve this in Jboss, edit the logging subsystem section in the file ${JBOSS_HOME}/standalone/configuration/standalone.xml.

<subsystem xmlns="urn:jboss:domain:logging:1.1">
   <logger category="com.mycompany.project.package">
     <level name="DEBUG"/>
   </logger>
   <root-logger>
     <level name="ERROR"/>
     <handlers>
       <handler name="CONSOLE"/>
       <handler name="FILE"/>
     </handlers>
   </root-logger>
</subsystem>

This will be applied to all webapps deployed in the Jboss instance.

Using git with a large subversion repos

I recently found myself working on a very large subversion (svn) repository. The repository (possibly) contains the company’s entire code base, spanning nearly 90,000 revisions. Even within the module I’m working on, there are over 300 branches.

Being a git convert, the first thought that occurred to me was to try git-svn, instead of moving back to svn. I love the ability to create multiple local feature branches. (I also prefer the way git merging works. But git-svn is restricted to the svn merge model).

For projects with many branches, it is recommended you clone one directory only. Otherwise, the resulting git repository will be many times larger than the original trunk.

git svn clone http://svn.mycompany.com/projectx/iteration123
Partial Cloning

However, I wanted to clone the trunk and a selection of branches. There are the options –trunk, –tags, –branches for svn repositories with non-standard layouts. Git-svn will also skip checking out paths specified with the option –ignore-paths.

After some experimentation, I found it easier to create an empty git repository, manually edit .git/config, and then fetch. Instead of using the command line options to clone.

git svn init http://svn.mycompany.com/projectx

Edit .git/config

[svn-remote "svn"]
url = http://svn.mycompany.com/projectx
fetch = trunk:refs/remotes/trunk
branches = branches/{iteration123}:refs/remotes/branches/*

The branches entry must contain a wildcard, or git-svn will complain with an error message along the lines of ‘glob needed’. I used the curly braces to fetch the branch iteration123 only. Multiple branches can be specified comma separated, like {iteration123,iteration124}.

I also restricted the fetch to recent revisions, by using the -r option

git svn fetch -r 80000:HEAD

Workflow

After the initial cloning hurdle, I found git-svn very straightforward to use.

At the start of each day, I merged changes from svn by using

git svn rebase

I committed changes to my local git repository with

git commit (-a)

Git-svn pushes each local commit as a separate commit to the remote svn. However, I committed very often and I really didn’t fancy polluting the svn log with lots of ‘reverting’, ‘trying x approach’. Therefore, I squashed all my commits for a scrum task into one commit before pushing the changes back to svn trunk.

git rebase -i branches/iteration123
git svn dcommit