jeudi mars 17, 2011

Portable Java EE 6 Web Maven Archetype

This blog has moved to alexismp.wordpress.com
Follow the link for the most up-to-date version of this blog entry.

With the growing use of Maven in enterprise projects, starting off with the best possible pom.xml is important. The good news is that there are a number of Java EE 6-related archetypes which can help you get started while offering IDE independance. The bad news is that their quality and portability in particular varies significantly.

The Java EE 6 platform APIs are now in Maven central : javaee-api:6.0 and javaee-web-api:6.0. These should be used with a provided scope and your POM should contain dependencies for the actual implementation (check this 3.1 download page for how to work with GlassFish).

Consider using that simple platform dependency rather than replying on archetypes introducing a long list of dependencies mixing APIs and implementations.

samedi janv. 16, 2010

Testing with the GlassFish Maven plugin and JavaDB Embedded

This blog has moved to alexismp.wordpress.com
Follow the link for the most up-to-date version of this blog entry.

Having GlassFish v3 usable in embedded mode made it easy to create a maven plugin with multiple goals (see this previous entry). This in turn makes it easy to configure the plugin for maven-driven unit testing. Here's an example :

<plugin>
    <groupId>org.glassfish</groupId>
    <artifactId>maven-embedded-glassfish-plugin</artifactId>
    <version>3.0</version>
    <configuration>
       <goalPrefix>embedded-glassfish</goalPrefix>
       <app>${basedir}/target/myapp.ear</app>
       <autoDelete>true</autoDelete>
       <port>8080</port>

    </configuration>

    <executions>
       <execution>
          <id>start-glassfish</id>
          <phase>pre-integration-test</phase>
          <goals>
             <goal>start</goal>
          </goals>
       </execution>
       <execution>
          <id>glassfish-deploy</id>
          <phase>pre-integration-test</phase>
          <goals>
             <goal>deploy</goal>
          </goals>
       </execution>
       <execution>
          <id>glassfish-undeploy</id>
          <phase>post-integration-test</phase>
          <goals>
             <goal>undeploy</goal>
          </goals>
       </execution>
       <execution>
          <id>stop-glassfish</id>
          <phase>post-integration-test</phase>
          <goals>
             <goal>stop</goal>
          </goals>
       </execution>
    </executions>
</plugin>

Now it's certainly nice to be able to automate tests right from a single pom.xml and not have to deal with starting, deploying, stopping the app server. It's even better when the runtime starts fast and uses only the required memory (as it is the case with GlassFish v3), but what about running tests involving a database? If a database server needs to be started using external tools (or worse, manually) it's a bit back to square "one".

This is where JavaDB embedded can come in handy. The trick with an application server like GlassFish is that it's not enough to use the embedded driver (org.apache.derby.jdbc.EmbeddedDriver), you also need to reference an embedded JTA datasource. GlassFish v3 ships with one such datasource pre-configured: jdbc/__TimerPool so lazy as I am, I simply reused this in by setup - using the following JPA persistence-unit enables my test to fire up an embedded (in-process) instance of JavaDB (no separate startup, no port used). As the names implies, this pool isn't really a general purpose one (it's used for by the Timer Service) so this is a bit of a hack. A handy one, but a hack.

<persistence-unit name="tempdb">
    <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
    <jta-data-source>jdbc/__TimerPool</jta-data-source>
    <properties>
       <property name="javax.persistence.jdbc.driver" value="org.apache.derby.jdbc.EmbeddedDriver"/>
       <property name="eclipselink.target-database" value="DERBY"/>
       <property name="eclipselink.ddl-generation" value="drop-and-create-tables"/>
    </properties>
</persistence-unit>

You see here that I use the drop-and-create-tables ddl generation strategy (create-tables would work too) and consider the database to be volatile. The next step would be to run all of this in-memory and no longer write files to disk (which shouldn't be that hard).

jeudi sept. 18, 2008

Building GlassFish v2 from source

Why build from source? First, because as with any open source projects, if there's a bug \*you\* can fix it. Second because you can get money for that. Finally, because even with GlassFish v3 Prelude around the corner, GlassFish v2 is still going to be in production for a long period at many customer sites.

v3 is very easy to build using the latest and greatest svn and mvn while building GlassFish v2 from source still requires CVS, maven 1.0.2 (1.1 doesn't work) and Java 5 (no Java 6). All this is detailed on this wiki page. The following is a stripped down version of the process for GlassFish v2ur2 (tagged SJSAS91_UR2_BRANCH).
Update: the tag for v2.1, released in January 2009 is SJSAS-9_1_1-B60E-23_Dec_2008.
Update: the tag for v2.1.1, released in october 2009 is SJSAS-2_1_1-B31G-19_Oct_2009.

First, make sure you have Java 5 as de default version by setting JAVA_HOME appropriately. Also set MAVEN_HOME to use 1.0.2 and MAVEN_OPTS to "-Xmx1024m". Finally, have $HOME/build.properties configured (or pass those as -D maven options):
glassfish.os.name=<OS Name: Possible values : WINNT | SunOS | Linux | SunOS_X86 | Darwin>
glassfish.cvs.username=<java.net_id>

The first step is the CVS checkout of the bootstrap (first magic string is the branch tag):
% cvs -d :pserver:username-AT-cvs.dev.java-DOT-net:/cvs login
% cvs co -r SJSAS91_UR2_BRANCH glassfish/bootstrap
% cd glassfish/bootstrap

This should complete in a matter of seconds.

The second step combines the full checkout and build process (second magic string is the correct set of maven goals)
% maven bootstrap checkout build build-jarinstaller

Checking out the entire source tree takes 15 minutes (modulo your bandwidth of course). The rest of the process takes another 15 minutes on my fairly recent laptop (and compiles around 10k classes in the process). The resulting installer jar can then be found in the ./publish directory:
% ls ./publish/\*.jar
glassfish-installer.jar

The -Dmodules= flag helps you checkout or build a specific set of modules. This and a lot more is documented on the wiki. Julien discussed building v3 a few weeks back. Whatever the version, remember we like bug reports and patches even more! :)

About

This blog has moved

Alexis Moussine-Pouchkine's Weblog

GlassFish - Stay Connected

Search

Archives
« avril 2014
lun.mar.mer.jeu.ven.sam.dim.
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today
Blogroll

No bookmarks in folder

News

No bookmarks in folder