Install a jar file into maven's local repository

Sometimes, while using maven to build your projects, it is necessary to add a needed jar file directly into your local repository. This should not be a need if you have a remote repository correctly setup, but it might be useful if it is a too bureaucratic task or any other reason.

It is as simple as this. Having the file to be installed in your local repository in the local folder, issue the command below to install it.

mvn install:install-file -DgroupId=<MVN_GROUPID> -DartifactId=<MVN_ARTIFACTID> -Dversion=<MVN_VERSION> -Dpackaging=jar -Dfile=<JAR_FILE_TO_INSTALL>

Could be useful! ;)

Find the name of your session bean in JBoss

If you are writing JEE applications, you will most likely write a Session Bean to provide your View Tier with the services it need. This Session Bean is reached by the client application through a service called JNDI.

The problem is that each Application Server uses a different JNDI provider and this makes portability very hard to achieve. I wrote the code below to allow me to access the JNDI service and find my Session Bean. Please note that this would be much better placed in the container configuration file and not in the code, as it is here.

protected static Context getInitialContext( ) throws javax.naming.NamingException {
  Properties p = new Properties( );
  p.put(Context.INITIAL_CONTEXT_FACTORY,"org.jnp.interfaces.NamingContextFactory");
  p.put(Context.URL_PKG_PREFIXES,"org.jboss.naming:org.jnp.interfaces");
  p.put(Context.PROVIDER_URL, "jnp://localhost:1099");
  return new javax.naming.InitialContext(p);
}


This method will return a java.naming.Context object which can be used for the lookup on the service, like this:


PatientServices patientServices = (PatientServices)jndiContext.lookup("PatientBean/remote");


And how can you find the name under which your bean has been published on the application server? Well, in JBoss all you need to do is access the jmx-console (default URL is http://localhost:8080/jmx-console/). On the jboss session from this page, find the JNDIView service. Click on it and a new page will display on your browser.
On this new page there will be a java.lang.String list() MBean operation, and clicking on the invoke button the names of all available JNDI names will be shown on a tree-like structure which composes the name under which your Session Bean is registered on the JNDI service.

Maven Profiles

I was struggling with some different configuration files for my development and production environment. As a "weekend-free-time-developer-now-that-I-changed-into-management", my development environment is restricted. So I use the same instance of MySQL for the production database and run some tests on the same server with a different schema and configuration.

Using maven as a build/management tool improved my a lot my performance, but these different environments still gave me some headache. So I decided to leave laziness aside and configure some profiles in my pom files.

Maven profiles allow you to prepare different sets of configuration. There are for different types of profiles, defined in different files and with different purposes:

1. Per Project: Defined in the POM itself (pom.xml).
2. Per User: Defined in the Maven-settings (%USER_HOME%/.m2/settings.xml).
3. Global: Defined in the global maven-settings (%M2_HOME%/conf/settings.xml).
4. Profile descriptor: a descriptor located in project basedir (profiles.xml)

I decided to use the type number 1, which is a Per-Project configuration type, and unlike number 4 (which has a restricted scope) which is also a Per-Project configuration type it has the ability to change a lot of the project settings because it is in the same pom file as the projects' specifications themselves.

For starters, I wanted to have different jboss' data source xml files for production and development environments. As Maven works with a hierarchy of configuration files I figures the less intrusive way to set the build configuration was to have different folders for each environment. So where I previously had /src/main/resources/WEB-INF now I would have /src/main/resources/development/WEB-INF and /src/main/resources/production/WEB-INF. With the original single path, Maven did not need any special configuration to find my data source xml files (I love "convention over configuration"). With the 2 new folders, I had to add another layer to the hierarchy of Maven's configuration files and this layer would be the profiles.

In my pom.xml, I added a profiles section, obviously enough marked by the tag <profiles>. Here is what I added to my original pom.xml.

  <profiles>
    <profile>
      <id>env-dev</id>
      <build>
        <resources>
          <resource>
            <directory>src/main/resources/development</directory>
          </resource>
        </resources>
      </build>
      <activation>
        <property>
          <name>env-dev</name>
        </property>
      </activation>
    </profile>

    <profile>
      <id>env-prod</id>
      <build>
        <resources>
          <resource>
            <directory>src/main/resources/production</directory>
          </resource>
        </resources>
      </build>
      <activation>
        <property>
          <name>env-prod</name>
        </property>
      </activation>
    </profile>
        
  </profiles>


Now, you can tell maven to build based on different profiles. Where you normally would enter a command like mvn install now you should change to:

mvn install -P env-dev for development environment

OR

mvn install -P env-prod for production environment

After doing this, I was wondering... Which profile will maven choose to execute the build if I do not explicitly tell it?

That is very easy to check! Run the command:

mvn help:active-profiles

It will show you that there are no active profiles, but it will (wrongly IMHO) add BOTH (production and development) folders to your final build, and will not realize that those are actual resource folders.

One simple solution for this issue is to tell maven which profile should be used by default. I modified the profiles tag content to use the production environment as the default one, so this will force me during development to always add the "-P env-dev" while I am testing/developing and this should make me used to always tell maven what I really want. The way to tell maven which one is the default active profile is in bold below.

    <profile>
      <id>env-prod</id>
      <build>
        <resources>
          <resource>
            <directory>src/main/resources/production</directory>
          </resource>
        </resources>
      </build>
      <activation>
        <activeByDefault>true</activeByDefault>
        <property>
          <name>env-prod</name>
        </property>
      </activation>
    </profile>


Now, if you run mvn help:active-profiles again you will see that the env-prod is being used, which is the same as running mvn help:active-profiles -P env-prod.

$ mvn help:active-profiles
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'help'.
[INFO] ----------------------------------------------------------------------------
[INFO] Building Fisio EJB Component
[INFO] task-segment: [help:active-profiles] (aggregator-style)
[INFO] ----------------------------------------------------------------------------
[INFO] [help:active-profiles]
[INFO]
Active Profiles for Project 'com.jc.fisio:fisio-ejb:ejb:0.1-SNAPSHOT':

The following profiles are active:

- env-prod (source: pom)



[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 second
[INFO] Finished at: Sun Feb 11 18:13:13 BRST 2007
[INFO] Final Memory: 2M/5M
[INFO] ------------------------------------------------------------------------


Working with profiles is quite interesting, because it allows you to have multiple active profiles at the same time, providing a number of different combinations. It can be used to may purposes, like setting different application servers, web servers, snapshot version etc.

Setting Cygwin Bash Shell Looks

As I posted earlier, I like to use Cygwin as a *nix-like shell to use under Windows, because the command tool is IMHO terrible to use.

Cygwin has a lot of *nix functionalities which are not supported under windows default installation which forces you to install a big variety of software from different vendors.

Cygwin has its own port of bash shell, but on the default installation the looks are kind of dull. I use rxvt port for cygwin to start my shell and I used some configuration settings as suggested by this article.

So, with small changes to the suggestions of the author to have a larger buffer and the size of the started window I came with this .Xdefaults file. It shold be placed in your home directory.

! ~/.Xdefaults - X default resource settings
Rxvt*geometry: 120x60
Rxvt*background: #000020
Rxvt*foreground: #ffffbf
!Rxvt*borderColor: Blue
!Rxvt*scrollColor: Blue
!Rxvt*troughColor: Gray
Rxvt*scrollBar: True
Rxvt*scrollBar_right: True
Rxvt*font: Lucida Console-12
Rxvt*saveLines: 10000
Rxvt*loginShell: True
! VIM-like colors
Rxvt*color0: #000000
Rxvt*color1: #FFFFFF
Rxvt*color2: #00A800
Rxvt*color3: #FFFF00
Rxvt*color4: #0000A8
Rxvt*color5: #A800A8
Rxvt*color6: #00A8A8
Rxvt*color7: #D8D8D8
Rxvt*color8: #000000
Rxvt*color9: #FFFFFF
Rxvt*color10: #00A800
Rxvt*color11: #FFFF00
Rxvt*color12: #0000A8
Rxvt*color13: #A800A8
Rxvt*color14: #00A8A8
Rxvt*color15: #D8D8D8
! eof

Later I did another small change on the cygwin.bat file to use vim instead of vi as the default editor. The cygwin.bat file can be found on the installation directory of cygwin. Save the original file with another name and then replace it with the following content.

@echo off
C:
chdir C:\cygwin\bin
set EDITOR=vim
set VISUAL=vim
set CYGWIN=codepage:oem tty binmode title
rxvt -e bash --login -i

Now when you start cygwin, the shell window will look like the one on the right (click on it to see a larger version). Play around with the collor definitions on the .Xdefaults file to have a setup that pleases you. .Xdefaults gives a lot of possibilites and you can see some examples here, here and here.