Sunday, November 9, 2014

Resource in Maven POM

Recently I was engaged to a project which convert a legacy ant build application into Maven build. My main application project has several sub projects. One child project fully contained sql scripts and cron job scripts. So I had to find where to include these sql and .sh files in the maven structure. I google and went through few articles to find out the correct place.

There is no clear cut solution I found. Some people suggest to put it into resources folder and some suggest to use separate folder. So, I thought to go ahead with a separate folder because the content of resource folder will attach to ear once I build it ( but still we can exclude them. Yet I thought it could be messy).


Resources

While surfing the web, I found more about Resources. We can include our separate folder into jar file. In my case, I do not want sql and .sh files to available in final jar. I just want to keep those in the same project. Let's see where to include those files and how to bundle our own folder into a jar.


Below is the apache introduction about Resources..
" Resources is a nice feature of build elements is specifying where resources exist within the project. Resources are not (usually) code. They are not compiled, but are items meant to be bundled within your project or used for various other reasons, such as code generation"

So I included all my sql and .sh files in its own directory instead put them in src/main/resource/scripts/sql, Now my sql and .sh files are located in src/main/scripts/sql and src/main/scripts/sh folders respectively. When I build the project, scripts folder is not included to jar.

Say, now I need to build a jar including the sql and sh files.

For this I used JAR plugin to bundle the resource correctly, and I would specify resources similar to the following:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <build>
  ...
  <resources>
   <resource>
    <targetPath>scripts/sql</targetPath>
    <filtering>false</filtering>
    <directory>${basedir}/src/main/scripts</directory>
    <includes>
     <include>synctableA.sql</include>
    </includes>
    <excludes>
     <exclude>**/*.properties</exclude>
    </excludes>
   </resource>
  </resources>
  <testResources>
   ...
  </testResources>
  ...
 </build>
</project>


See below detail about each tag.

  • resources: is a list of resource elements that each describe what and where to include files associated with this project.
  • targetPath: Specifies the directory structure to place the set of resources from a build. Target path defaults to the base directory. A commonly specified target path for resources that will be packaged in a JAR is META-INF.
  • filtering: is true or false, denoting if filtering is to be enabled for this resource. Note, that filter *.properties files do not have to be defined for filtering to occur - resources can also use properties that are by default defined in the POM (such as ${project.version}), passed into the command line using the "-D" flag (for example, "-Dname=value") or are explicitly defined by the properties element. Filter files were covered above.
  • directory: This element's value defines where the resources are to be found. The default directory for a build is ${basedir}/src/main/resources.
  • includes: A set of files patterns which specify the files to include as resources under that specified directory, using * as a wildcard.
  • excludes: The same structure as includes, but specifies which files to ignore. In conflicts between include and exclude, exclude wins.
  • testResources: The testResources element block contains testResource elements. Their definitions are similar to resource elements, but are naturally used during test phases. The one difference is that the default (Super POM defined) test resource directory for a project is ${basedir}/src/test/resources. Test resources are not deployed.
Hope this would help to increase your knowledge about maven resources.

Friday, February 14, 2014

Use OpenEJB for Junit Test

I was struggling yesterday to find a way to do Junit test for EJB and I found OpenEJB. But  the configuration gave me errors. So I thought to write a complete example because I couldn't find it anywhere.

First lets create a simple ejb.
Here is the interface

  package com.imesh.testejb;
  import javax.ejb.Local;
  @Local
  public interface IHello {
    public string sayHi();
  }
OK now the bean class.
 
  package com.imesh.testejb;
 
  import javax.ejb.Stateless;
  /**
   * Session Bean implementation class Hello
   */
  @Stateless
  public class HelloBean implements IHello{
    /**
     * Default constructor.
     */
    public HelloBean() {
    }
    @Override
    public string sayHi() {
      return "HI";
    }
  }

Write our unit test class.

package com.imesh.test.ejbtest;
import static org.junit.Assert.*;
import java.util.Properties;
import javax.ejb.EJB;
import javax.naming.InitialContext;
import org.apache.openejb.api.LocalClient;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
@LocalClient
public class HelloBeanTest {
 @Before
 public void setUp() throws Exception {
     Properties properties = new Properties();
     properties.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.apache.openejb.client.LocalInitialContextFactory");
     properties.setProperty("openejb.deployments.classpath.include", ".*");
     initialContext = new InitialContext(properties);
 }
 @After
 public void tearDown() throws Exception {
 }
 @Test
 public void testSayHi() {
   bean = (IHello) initialContext.lookup("HelloBeanLocal");
   assertEquals("Hi", bean.sayHi());
  
 }
  private InitialContext initialContext;
 private IHello bean ;
}

Ok now we need ejb-jar.xml file which should be located in the META-INF folder.
ejb-jar.xml contains nothing but   just empty tag. I couldn't run the unit test without this xml but nobody mentioned about this xml in examples. The error I got is relate to the JNDI name not found.
If you do use annotation in your ejb class, ejb-jar.xml will overwrite your annotation. So you can add this xml to test > resources > META-INF folder because we need this only for unit test. 
Next is dependencies. You may not want slf4j dependency. But I had some errors without it.

            org.apache.openejb
            openejb-core
            3.1.3
            test
       

       
            org.slf4j
            slf4j-nop
            1.6.1


 That's it. We are done. you can compile and run the unit test.