Here is my letter :

This email is a tentative to gather and synthesize all my thought following the yesterday announce on in.relation.to about Seam 3 reorganization. I want it to be seen as a positive feedback. I don’t pretend to have all the answers but being someone external to Red Hat and having worked with other frameworks / technologies give me (I think) a better “big picture” view and a more objective perception of the matter.

Who’s talking ?

I’m not going to tell you all my life here. But it can help for my legitimacy to know that I graduated from a famous IT School in 1995 (yes I’m 40) and had been working in IT since then. I started with C / C++ and then Lotus Domino (talking about mistakes). I started looking into Java in 1997 as a hobby and more seriously for work in 2001. I worked with a lot of Java frameworks : pure servlet and JSP, Struts 1.X, iBatis, Spring, JSF, Hibernate, EJB3, Seam 2 (I started with 2 beta in 2007) to finally adopt Java EE 6.

I’d been working alone for 10 years then after that as a CTO in a small Web Agency (where I learnt some web marketing) and I’ve bee working since 2009 as a consultant in an IT Consulting company specialized on Java. My Job is to audit applications, design new application as an architect and doing support to other developer on a bunch of technologies.

History (knowing our “opponent”)

Again, I’m not going to write a novel here but I think it’s better to put things in perspective.

JCP had clearly a bad start. Most of specification in J2EE before Java EE 5 were full of flaws (especially EJB 1.X and 2.X). That’s mainly the reason why Spring was created and has been so successful : it was a pragmatic and rather clean way to address Java Enterprise needs. From a lightweight solution spring grown to a heavy but quite consistent eco-system and today it has a big market share in the Java Industry. Meanwhile spring was getting bigger, the JCP somehow took notice of its past errors and worked to change things and provide nice specification for the new Java EE edition. But we had to wait for Java EE 6 to get an official standard that was able to compete with Spring (the de Facto Standard) thanks to CDI and the tremendous work that JBoss guys put in it.

So today we are in a paradoxical situation where the official Java EE stack is the challenger of the de facto standard : Spring. To be honest, Java EE is better than core Spring but not way better. Also Spring has a lot of popular modules that help developers in their daily work (a big eco-system). A lot of company have invested on Spring (training, support, etc…) and they have no obvious reason to switch to Java EE 6. If we want to bring them to this switch we have to build something better and something bigger

What should be Red Hat goals ?

The main goal for Red Hat is to sell licenses and support. I don’t know your exact income on JBoss activity but with a real big Java EE adoption, those incomes should rise very clearly. Right now most of the JBoss EAP server I see at my customer run Spring application and most of these server could be switched to Tomcat or Jetty tomorrow without any big trouble (the same for most WAS or Weblogic).

A secondary goal (that interest me more) is philosophical. The Java EE 6 stack is a community creation, its blue print doesn’t belong to a single shop and tomorrow if someone want to propose something new he could contribute to this community. Ok, it’s not perfect but for me it’s far way better than having VMWare deciding what’s good and wrong for me. I often say to Spring Fanboys that if they want to have one editor to decide for them they’d better switch to .Net : Microsoft does a better Job than VMWare and C# is better than Java . The advantage of Java eco-system is the community. So the Goal is to use the force of this community and bring open solutions to them.

Creating a big and good CDI eco-system will create value, bring real competition to the Java stack and create more business for Red Hat (AS license or support on main CDI components)

Why CDI is so special

CDI is not a spec among others. It’s the long awaited cement in Java EE stack. It could have been an extension of EJB spec but it was clever to create it as a separate spec and allow it to deal with EJBs. CDI is the first Java EE spec that contains in its DNA a natural extension mechanism. And last but not least CDI is probably the first Java EE spec to be usable in its V 1.0 (perhaps with Jax-RS).

A common critic to Java EE is that it has a very long cycle between each iteration and that it delivers outdated specs. Another common critic is that it provides a bunch of specs that doesn’t work well together.

This second critic was addressed by Seam 2. Seam was a big help to make Java EE 5 easy to use, but as you know it was proprietary.

CDI address both critics : it has the potential to provide the same services than Seam 2 and it is a good way to extend Java EE between two versions.

To sum up CDI is a central spec for Java EE (it’s its spine) :

1. CDI is the cement between main Java EE spec
2. CDI the “melting pot” engine for adding new spec in Java EE. First in a proprietary approach and then by standardization in next EE version.
3. For extension that can’t be integrated in Java EE (like Seam social) it’s an elegant and seamless way to enhance the stack.

Past and present Errors

Error 1 : a bad name

The first error in my opinion was to call it “Seam 3″. This bad choice triggered these pb :

1. giving the impression that Seam 3 was an evolution of Seam 2. Which it is not.
2. creating the obligation to build a compatibility module from Seam 2 to Seam 3. This module is costing a lot of energy to the community and will only produce deception
3. Hiding the CDI nature of these extensions by calling them after the name of an “old” JBoss proprietary framework

Error 2 : pretending Spring doesn’t exist

Ignore existing market is a big mistake. Spring is well implanted and doing as if it wasn’t there is wrong. I think a better way would be to adopt the following philosophy : “We know that you had to use this proprietary framework because there was nothing else but now we will show you something new, better, but that can use your Spring eco-system”. Yes the Spring bridge is not an option, It’s a priority. You have to help people switching by giving them a way to use their Spring components so they don’t feel lost and can use Spring module until Seam has the equivalent functionality.

Spring team is totally ignoring Java EE. Their ref doc is full of J2EE, EJB 2.1 and nothing about CDI or EJB 3. We have to show the Java community that we’re more open than them and care about people using Spring to come, see and perhaps adopt the standard. The idea is to behave at the opposite of the locking VMWare strategy by being opened and avoiding trolls and misinformation like they do.

Error 3 : eating our own dog food with Seam university.

Don’t get me wrong : the idea of Seam University website is great. What is not so great is to use our tool to create the site. We don’t have time to build something neat, so it’ll be crappy and we’ll lost time on it. Result : bad impression and time wasted. Other Framework don’t use themselves to create their website, they use standard tools. We should do the same for the Seam website. People are waiting for simple demo and example not a big steam machine like the Seam Wiki is today.

Error 4 : mix internal functioning with façade functioning of the project

Having Seam module created near their mother project (Hibernate, Resteasy…) is not a bad idea. The bad idea is to make them disappear from the Seam stack. You can have CDI-persistence (note I didn’t wrote CDI-Hibernate) driven by Hibernate project , but it should be visible in both Seam stack and hibernate. Because One can discover it while using Hibernate or while looking for a persistent CDI extension.

Error 5 : giving the impression that those modules will have adherence to Jboss implementation

Calling the module Hibernate-CDI or RestEasy-CDI is a big step back (even if you keep portability). Tomorrow developers on WAS or Glassfish won’t choose them because it doesn’t support JPA but hibernate (it’s in the name). A non sense after all the effort that Jboss has injected in working on standard.

It’s important that Seam appear as collection of CDI extension that allow to leverage standard Java EE. Having them under one umbrella allow Red Hat to sell optional support for them if people want to use them on WAS, Glassfish, Tomcat or Resin.

What should Seam 3 be (according to me)

Seam should be turned to the community. I don’t know if Red Hat would be ok to do that but the core project should be outside of JBoss and community driven. It would be the best solution to gather our effort with those of CDI Source, Codi, Caucho and others.

Seam 3 should run on all CDI implementation. That’s a priority (today, Solder doesn’t work on Candi, I didn’t tested on Open WebBeans but I guess there are issues).

Seam should provide light modules with good documentation and example. I mention that because i have he impression that Solder is becoming a kind of trash can. It’s not good. On the other way the split between persistence and transaction was a good move in my opinion

Seam should have a clear roadmap and timeline. We have to communicate, communicate and communicate. Don’t forget that we have to convince people using an equivalent solution. We must show why we are better and that we have a clear Goal.

Thanks for your time reading my long mail. I hope it’ll be useful and I’m ready to contribute to these orientation.

regards,

Antoine

UPDATE : Shane Bryzak project leader on Seam 3 posted an update this morning, to explain there is something in preparation around Seam.

Starting the tutorial

We start this tutorial with 3 Eclipse projects : an EAR, an EJB and a WAR project. These projects are showed in the following picture

The 3 projects are linked with the Eclipse configuration files which contains informations about EAR, EJB and WAR projects. In this article the projects are based on JBoss Seam, but all the tutorial could be used in any project type.

On the disk, the 3 projects are 3 directories in the workspace folders. Useless to say it’s not the Maven way to organize projects.

Creation of the parent Project

First step, we create a Maven parent project which will contain our EAR, EJB and WAR projects (that Maven call modules). In this parent project we can define global parameters for the modules. To create this project click on “File/New/Porject…”

Choose Maven Project in the Maven category and click on Next, this opens the “New Maven Project” wizard :

You can go to the next step after checking that “Create a simple project” is unchecked.

In this dialog box you have to choose an archetype (a template for your project). In Catalog choose Nexus Indexer which brings a richer list than the internal default one. In the filter field enter “pom” to reach the “pom-root” archetype”. Select it and click on “Next”.

In this last dialog box you choose the project name. click on “Finish”. Now you have a new project in your workspace. In my case it’s “pfm77-parent”

Creating the Maven modules

In the same way we created parent project, we’re going to create the children projects or modules. click on “File/New/Project…”

Choose “Maven Module” then click on “Next”. A new wizard opens :

Enter the name for the EAR module and the name of the parent project then click on “Next.

Don’t forget to choose “Nexus Indexer” in the catalog, enter “ear” in the filter field. Choose the “ear-jee5″ archetype then click on “finish”

To create the EJB and WAR modules, we’ll use the same wizard choosing archetypes “ejb-jee5″ and “webapp-jee5″.

After all those wizards and clicks, we have 4 new projects in the workspace :

The physical structure of these Eclipse projects are different. If you look on your disk, you’ll see a Maven hierarchy (a main project and modules in in the folder of the main project). It’s one of the m2eclipse benefits : supporting sub-projects in Eclipse. But it’s not the only advantage of the plugin.

Benefits of m2eclipse

1) Managing sub-projects in Eclipse

As we saw, you can have a Maven hierarchy that m2eclipse make look likes different Eclipse project in the IDE. This also works when you import existing maven project in the worskpace from the disk or versioning system.

2) Managing Maven dependencies

The plugin use the pom.xml files to download and add jar files in your project.

3) Maven build in Eclipse

The least we can wait for this plugin. A m2eclipse project has 2 builders : the standard Eclipse one and the maven one.

4) A nice user interface to manage pom.xml files

You can use this interface to look for dependencies or exclude a sub-dependency easily. It was rather bugy in the past but with version 0.99 of m2eclipse it starts to be very usefull.

5) Automatic management of Eclipse projects configuration

That’s an important benefit that is not very well documented on m2eclipse site. M2eclipse uses pom.xml information to generate and maintain Eclipse configuration files for the project. For instance the projects we just created are not Eclipse project. They were created from Maven Archetypes that have nothing to do with Eclipse. So the eclipse configuration files of these new project (.classpath, .project files and .settings folder) were generated by m2eclipse from the pom files. When pom files are modified, m2eclipse will change Eclipse configuration files automatically. For instance, let’s have a look at the Facets of the EJB project (right-click on the project, and choose properties/facets) :

M2eclipse have added this EJB3 facets by analyzing the pom.xml file. So if you change Eclipse configuration on the project there can be some chance that you touch a configuration driven by m2eclipse. So take care of your modification. To be sure you won’t go battle wth m2eclipse in the configuration you should check the m2eclipse documentation. This page show all the Maven parameters (with green checkboxes) that are used by m2eclipse to build and maintain Eclipse WTP configuration files.

To finish with this point, you’ll have to be extremely carrefull when you put those project under versioning system. The best solution is to ignore Eclipse configuration files and let m2eclipse do the job on the other systems (you’ll have to create local configuration on each IDE to configure information that are not in Maven files like deploying servers for instance).

Copying Files

Let’s go back to our tutorial : moving WTP projects to maven/WTP projects. The next step consist to copy files from our old WTP project to the newly created Maven/WTP projects. You can do this by dragging files from file system (Explorer, Finder, or whatever you use) to Eclipse using the “resources” perspective which is the more close to filesystem perspective. To keep it simple try to stick with the default Maven layout, It will make pom files lighter.

• For the EAR module you’ll put the content of META-INF in src/main/application/META-INF all the other files in te project will be build from pom.xml
• For the EJB module, all your classes should be put in src/main/java, resources files like properties or META-INF folder should be in src/main/resources.
• For the WAR module you’ll use the same folders as EJB for classes and resources. The site files will be copied in src/main/webapp folder (be carefull and don’t take the WEB-INF/lib folder)

You should ignore Manifest files in all the project because they can cause runtime errors.

Now we have to deal with our pom files

Pom pom pom pom

It’s not a symphony but almost (sorry for that). The setting of our 4 pom.xml files will ask some patience (it’s the Maven feng-shui side) but we will get trough.

Parent project

I won’t detail all my pom.xml files content : I want to keep my readers till the end. Instead I’ll show you the result and comment the main part of each file

• Introduction : here I tell Maven that it is a pom project that drive construction of sub-projects (modules).
• modules : here are the modules contained by this parent project.
• properties : here I define variables that will be used in configuration of all the modules (libraries version for instance)
• repositories : in this section I add Maven repositories used by my project. For me it’s JBoss repositories for Seam and java.net to get all Jee5 dependencies
• dependencyManagement : In this part, I declare all the dependencies used by my modules. Declaring them here, I can set their version once for all.
• build : in this final section I can set up compilation configuration once for all.

<?xml version="1.0" encoding="UTF-8"?>
<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/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>cos</groupId>
  <artifactId>pfm77-parent</artifactId>
  <packaging>pom</packaging>
  <version>0.0.1-SNAPSHOT</version>
  <name>pfm77-parent Multi Project</name>
  <url>http://maven.apache.org</url>
  <modules>
    <module>pfm77-ear</module>
    <module>pfm77-ejb</module>
    <module>pfm77-war</module>
  </modules>

  <properties>
    <seam.version>2.0.3.CR1</seam.version>
    <jsf.version>1.2_10</jsf.version>
    <richfaces.version>3.2.1.GA</richfaces.version>
  </properties>

  <repositories>
    <repository>
      <id>jboss</id>
      <name>JBoss Repository</name>
      <url>http://repository.jboss.org/maven2</url>
      <snapshots>
        <enabled>false</enabled>
      </snapshots>
    </repository>
    <repository>
      <id>jboss-snapshots</id>
      <name>JBoss Snapshot Repository</name>
      <url>http://snapshots.jboss.org/maven2</url>
      <releases>
        <enabled>false</enabled>
      </releases>
      <snapshots>
        <enabled>true</enabled>
      </snapshots>
    </repository>
    <repository>
          <id>java.net1</id>
          <name>Java.Net Maven1 Repository, hosts the javaee-api dependency</name>
          <url>http://download.java.net/maven/1</url>
          <layout>legacy</layout>
      </repository>
  </repositories>

 <dependencyManagement>
 <dependencies>

  <dependency>
      <groupId>commons-beanutils</groupId>
      <artifactId>commons-beanutils</artifactId>
      <version>1.8.0</version>
      <scope>compile</scope>
       </dependency>
        <dependency>
      <groupId>org.ostermiller</groupId>
      <artifactId>utils</artifactId>
      <version>1.07.00</version>
      <scope>compile</scope>
    </dependency>
    </dependencies>
 </dependencyManagement>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.5</source>
          <target>1.5</target>
        </configuration>
      </plugin>

    </plugins>
  </build>

</project>

EAR project

In the pom file, we can get rid of compilation plug-in because we configured it in the parent project. But we’ll have to add all the depending jars and their version. The m2eclipse auto-completion tools are very usefull for this. Right-click on the project and choose “Maven/add Maven dependency”. The following dialog box opens

With this box you can search in Maven repositories the right jar and version for your project and add it the pom.xml file. With time some sub-depencies can appear in the project. You can exclude them by using the “Dependency graph” in pom editor. This view show a graph like this one :

If yo want to exclude a jar you can do it via the context menu and choosing “Exclude Maven Artefact…” (wasn’t working in version 0.98 of m2eclipse). Now, back to our pom file of EAR module here are its content

• header : I specify that it’s an EAR module and I don’t forget to point to the Parent project
• In the dependencies I don’t forget EJB and War modules
• In the build section I add the Maven EAR plugin. In the configuration of the plugin I give the directory where to put the lib and ask Maven to generate my application.xml file
• In the modules section of the plugin, I add my EJB and WAR modules that I defined at the beginning of the file as dependencies

<?xml version="1.0" encoding="UTF-8"?>
<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/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <artifactId>pfm77-parent</artifactId>
    <groupId>cos</groupId>
    <version>0.0.1-SNAPSHOT</version>
  </parent>
  <groupId>cos</groupId>
  <artifactId>pfm77-ear</artifactId>
  <packaging>ear</packaging>
  <version>0.0.1-SNAPSHOT</version>
  <name>pfm77-ear JEE5 Assembly</name>
  <url>http://maven.apache.org</url>

  <dependencies>
    <dependency>
      <groupId>cos</groupId>
      <artifactId>pfm77-ejb</artifactId>
      <version>0.0.1-SNAPSHOT</version>
      <type>ejb</type>
      <scope>compile</scope>

    </dependency>
    <dependency>
      <groupId>cos</groupId>
      <artifactId>pfm77-war</artifactId>
      <version>0.0.1-SNAPSHOT</version>
      <type>war</type>
      <scope>compile</scope>

    </dependency>

    <dependency>
      <groupId>org.jboss.seam</groupId>
      <artifactId>jboss-seam</artifactId>
      <version>${seam.version}</version>
      <type>ejb</type>
      <scope>compile</scope>
      <exclusions>
        <exclusion>
          <groupId>javax.el</groupId>
          <artifactId>el-api</artifactId>
        </exclusion>
        <exclusion>
          <artifactId>javassist</artifactId>
          <groupId>javassist</groupId>
        </exclusion>
        <exclusion>
          <artifactId>dom4j</artifactId>
          <groupId>dom4j</groupId>
        </exclusion>
      </exclusions>
    </dependency>

    <dependency>
      <groupId>org.ostermiller</groupId>
      <artifactId>utils</artifactId>
    </dependency>

    <dependency>
      <groupId>org.richfaces.framework</groupId>
      <artifactId>richfaces-api</artifactId>
      <version>${richfaces.version}</version>
      <scope>compile</scope>
      <exclusions>
        <exclusion>
          <artifactId>commons-collections</artifactId>
          <groupId>commons-collections</groupId>
        </exclusion>
        <exclusion>
          <artifactId>commons-logging</artifactId>
          <groupId>commons-logging</groupId>
        </exclusion>
      </exclusions>
    </dependency>

  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-ear-plugin</artifactId>
        <version>2.3.2</version>
        <configuration>
          <version>5</version>
          <defaultLibBundleDir>lib</defaultLibBundleDir>
          <generateApplicationXml>true</generateApplicationXml>

          <modules>
            <ejbModule>
              <groupId>cos</groupId>
              <artifactId>pfm77-ejb</artifactId>
            </ejbModule>
            <ejbModule>
              <groupId>org.jboss.seam</groupId>
              <artifactId>jboss-seam</artifactId>
            </ejbModule>
            <webModule>
              <groupId>cos</groupId>
              <artifactId>pfm77-war</artifactId>
              <contextRoot>PFM77</contextRoot>
            </webModule>
          </modules>

        </configuration>
      </plugin>
    </plugins>
    <finalName>pfm77-ear</finalName>
  </build>

</project>

EJB project

Next step the EJB pom file. Not a lot of things to say about it except concerning the Maven EJB plugin which is used to set the EJB version.

<?xml version="1.0" encoding="UTF-8"?>
<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/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <artifactId>pfm77-parent</artifactId>
    <groupId>cos</groupId>
    <version>0.0.1-SNAPSHOT</version>
  </parent>
  <groupId>cos</groupId>
  <artifactId>pfm77-ejb</artifactId>
  <packaging>ejb</packaging>
  <version>0.0.1-SNAPSHOT</version>
  <name>pfm77-ejb JEE5 EJB</name>
  <url>http://maven.apache.org</url>
  <dependencies>

    <dependency>
      <groupId>javaee</groupId>
      <artifactId>javaee-api</artifactId>
      <version>5</version>
      <scope>provided</scope>
    </dependency>

    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.seam</groupId>
      <artifactId>jboss-seam</artifactId>
      <version>${seam.version}</version>
      <scope>provided</scope>

    </dependency>
    <dependency>
      <groupId>org.hibernate</groupId>
      <artifactId>hibernate-annotations</artifactId>
      <version>3.2.0.ga</version>
      <scope>provided</scope>
    </dependency>
    <dependency>
      <groupId>commons-beanutils</groupId>
      <artifactId>commons-beanutils</artifactId>
      <scope>provided</scope>
    </dependency>
    <dependency>
      <groupId>org.ostermiller</groupId>
      <artifactId>utils</artifactId>
      <scope>provided</scope>
    </dependency>
    <dependency>
    	<groupId>mysql</groupId>
    	<artifactId>mysql-connector-java</artifactId>
    	<version>5.1.6</version>
    	<scope>provided</scope>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-ejb-plugin</artifactId>
        <version>2.1</version>
        <configuration>
          <ejbVersion>3.0</ejbVersion>

        </configuration>
      </plugin>
    </plugins>
    <finalName>pfm77-ejb</finalName>
  </build>
</project>

WAR project

Last but not least the WAR pom file. Notice that we’re not using Maven war plugin in this pom file, the default values of War packaging are enough.

<?xml version="1.0" encoding="UTF-8"?>
<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/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <artifactId>pfm77-parent</artifactId>
    <groupId>cos</groupId>
    <version>0.0.1-SNAPSHOT</version>
  </parent>
  <groupId>cos</groupId>
  <artifactId>pfm77-war</artifactId>
  <packaging>war</packaging>
  <version>0.0.1-SNAPSHOT</version>
  <name>pfm77-war JEE5 Webapp</name>
  <url>http://maven.apache.org</url>
  <dependencies>

    <dependency>
      <groupId>javax.servlet</groupId>
      <artifactId>servlet-api</artifactId>
      <version>2.5</version>
      <scope>provided</scope>
    </dependency>

    <dependency>
      <groupId>javax.servlet.jsp</groupId>
      <artifactId>jsp-api</artifactId>
      <version>2.1</version>
      <scope>provided</scope>
    </dependency>

    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>

    <dependency>
      <groupId>org.jboss.seam</groupId>
      <artifactId>jboss-seam-ui</artifactId>
      <version>${seam.version}</version>
      <scope>compile</scope>
      <exclusions>
        <exclusion>
          <groupId>org.jboss.seam</groupId>
          <artifactId>jboss-seam</artifactId>
        </exclusion>
      </exclusions>
    </dependency>

    <dependency>
      <groupId>org.jboss.seam</groupId>
      <artifactId>jboss-seam-debug</artifactId>
      <version>${seam.version}</version>
      <scope>compile</scope>
      <exclusions>
        <exclusion>
          <groupId>org.jboss.seam</groupId>
          <artifactId>jboss-seam</artifactId>
        </exclusion>
      </exclusions>
    </dependency>

    <dependency>
      <groupId>org.jboss.seam</groupId>
      <artifactId>jboss-seam-pdf</artifactId>
      <version>${seam.version}</version>
      <scope>compile</scope>
      <exclusions>
        <exclusion>
          <groupId>org.jboss.seam</groupId>
          <artifactId>jboss-seam</artifactId>
        </exclusion>
      </exclusions>
    </dependency>

    <dependency>
      <groupId>org.richfaces.ui</groupId>
      <artifactId>richfaces-ui</artifactId>
      <version>${richfaces.version}</version>
    </dependency>

    <dependency>
      <groupId>org.richfaces.framework</groupId>
      <artifactId>richfaces-impl</artifactId>
      <version>${richfaces.version}</version>
      <exclusions>
        <exclusion>
          <groupId>commons-logging</groupId>
          <artifactId>commons-logging</artifactId>
        </exclusion>
        <exclusion>
          <groupId>junit</groupId>
          <artifactId>junit</artifactId>
        </exclusion>
        <exclusion>
          <groupId>javax.faces</groupId>
          <artifactId>jsf-api</artifactId>
        </exclusion>
        <exclusion>
          <groupId>org.richfaces.framework</groupId>
          <artifactId>richfaces-api</artifactId>
        </exclusion>
        <exclusion>
          <groupId>javax.servlet</groupId>
          <artifactId>servlet-api</artifactId>
        </exclusion>
        <exclusion>
          <groupId>javax.faces</groupId>
          <artifactId>jsf-impl</artifactId>
        </exclusion>
      </exclusions>
    </dependency>

  </dependencies>
  <build>

    <finalName>pfm77-war</finalName>
  </build>
</project>

Generating Eclipse configuration

Now that we have our pom files, we’ll ask m2eclipse to refresh eclipse config files by accessing the “Maven/update configuration file” in the context menu of each project. Doing this refresh .classpath, .project files and .settings folder of our projects.

First Maven build and first fix

From the context menu of the parent project (not the EAR), choose “Run as…/Maven install” or “Maven package”. Maven is launched but the build fails. Don’t panic this issue is caused by a conflict in Maven resolution and Workspace resolution. Disable Worksapce resolution in the parent project by choosing “Maven/Disable Workspace Resolution” in contextual menu of the parent project. Launch the build again and “voila”. You get an ear file in the target directory of the EAR project. In command line you’ll have to launch “mvn install” from parent project folder to have the same result.

What about WTP ?

Before using WTP to deploy your project you’ll have to copy the application.xml file from the target folder (of the EAR project) to the “src/main/application/META-INF” folder and do it again each time EAR modules change (which is not so often). And now ? Beleive it or not but it’s over and it works. In the server view choose your server (if you don’t have one you can create a “local deployer”). In the contextual menu choose “Add remove…” and add your project.

Then click on “publih” and tadaaa, your project is deployed with WTP (if it’s not, you just have to restart all this tutorial over ). The only issue is a WEB-INF directory in the root of the EAR which contains a copy of the lib directory of the good WEB-INF directory of the war module. This problem should be harmless for a local deployment and is caused by this Eclipse bug.

Conclusion

So m2eclipse is not working out of the box with WTP project. However it’s a powerfull tool even without this need. About Seam and Maven, JBoss is working on making developer life more simple. JBoss tools 3.1 should include extensions to ease the work with m2eclipse and Seam and Seam 3.0 should be totally mavenized, so easier to be build with Maven.

We’ll keep an eye on it…

See this code for instance :


@Name("registerHdl")
@Scope(ScopeType.CONVERSATION)
public class RegisterHandler implements Serializable{

(getters and setters skiped)
}


It defines a component in the conversation scope with a private field containing an entity which is outjected with “registrant” name.

Later we’ll want to use this variable in a view :

pages.xml :

...

register.xhtml :

...
Your name :

value="#{registrant.lastName}"/>
...


But it doesn’t work (an exception occurs when the form is submitted). We started a conversation in pages.xml and called the outjected “registrant” variable from registerHdl without any success.
So what went wrong ?
The problem is that the “registerHdl” component is never created and the call we made to “registrant” didn’t trigger this creation.
To trigger this creation we could have called a method of registerHdl. We could have mapped the fields with #{registerHdl.registrant} in the view after having defined getter and setter for registrant in the component. But ther’s a better way.
That’s here that @Factory start to be useful.


@Name("registerHdl")
@Scope(ScopeType.CONVERSATION)
public class RegisterHandler implements Serializable{

}


We deleted the @Out annotation and added a getter with the @Factory annotation. This new configuration triggers the creation of registerHdl component when we call #{registrant…} in our view.

To summarize @Out outjects a field as a context variable after the creation of the component and @Factory triggers if necessary the creation of the component to outject the return value of a method. @Out is only visible in the component life cycle and @Factory is visible in the whole application.
But that’s not the only difference between @Factory and @Out as we’ll see in part 2 of this article.