Providing version of your Seam app in your EAR or WAR

[gonorrhea]

What's the best practice of providing the build number or version of your Seam app in the EAR, for example?

Should we use the typical manifest.mf file and would that be generated by an Ant task during the packaging of the EAR/WAR?

I haven't seen this topic covered in the ref docs or the Seam books I've read.

Currently I am reading the app version (e.g. 0.8.0.1) from a DB table, but I don't feel that is the best way to solve this problem.

[lelleh]

It seems weird to have to update the DB if one for some reason would want to revert to an older version, and wouldn't it be difficult to have different versions deployed at the same time?

FWIW, I use the ant manifest task to create a manifest.mf. Apps pick up the version info the same way as org.jboss.seam.Seam does.

[gonorrhea]

manifest.mf seems like a good (standard) idea.  So why isn't it part of the seam-gen'd build.xml?

[gonorrhea]

So here's a start base on Java Development with Ant book, pg. 151:

<target name="create-manifest" depends="init" description="make the manifest">
               <tstamp>
                    <format property="buildtime"
                              pattern="yyyy-MM-dd'T'HH:mm:ss"/>
               </tstamp>
               <manifest file="${ear.dir}/META-INF/MANIFEST.MF">
                         <attribute name="built-by" value="Arbi"/>
                         <attribute name="built-on" value="${buildtime}"/>                         
               </manifest>
          </target>

So the key attribute here that is missing is the build number.  How is that generated?  Can we pull that number from the latest tag in SVN repo?  Or is it simply hard-coded in the build.xml?

Here is the MANIFEST.MF contents for facelets JAR:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0
Created-By: 1.5.0_12-b04 (Sun Microsystems Inc.)
Implementation-Version: 1.1.14

Also, do you store your MANIFEST.MF in the EAR META-INF or in a JAR META-INF or elsewhere?

[gonorrhea]

I attempted to deploy different versions of the same project (EAR) in the same JBoss instance (e.g. server/default/deploy) and there were classloading conflicts/problems on startup of JBoss.  I don't think you can isolate the different versions of the same apps unless they're deployed in their own JBOss instances.

The problem with my solution is the following (other than the fact that the update to the version column could be skipped or wrong version applied):

let's say you have version 1.0.0.0 of app Foo deployed on server A (QA1).

and you also have version 1.0.0.1 of app Foo deployed on server B (UAT1).

But the foo-ds.xml files on both servers point to the same RDBMS (same server and db).

So you're screwed.  Because there is only one row in the ApplicationMetaData table per app.  Any update you issue to the version column for that record will reflect in the ApplicationMetaData page for both apps on both servers.

Unless I refactor the db schema to accommodate this...

[luxspes]

Arbi Sookazian wrote on May 22, 2009 23:11:


I attempted to deploy different versions of the same project (EAR) in the same JBoss instance (e.g. server/default/deploy) and there were classloading conflicts/problems on startup of JBoss.  I don't think you can isolate the different versions of the same apps unless they're deployed in their own JBOss instances.

Welcome to classpathhell, hopefully OSGi and JSR 291 will solve that, but until JBoss get good support for that...

[luxspes]

Arbi Sookazian wrote on May 22, 2009 23:02:



So the key attribute here that is missing is the build number.  How is that generated?  Can we pull that number from the latest tag in SVN repo?  Or is it simply hard-coded in the build.xml?

You can use the BuildNumber ant task for that.

[luxspes]

Or, if you are really looking for powerful repository based build automation approach, you can go for Ant Ivy and its more advanced build number management task

[gonorrhea]

Francisco Peredo wrote on May 23, 2009 05:22:

Arbi Sookazian wrote on May 22, 2009 23:11:


I attempted to deploy different versions of the same project (EAR) in the same JBoss instance (e.g. server/default/deploy) and there were classloading conflicts/problems on startup of JBoss.  I don't think you can isolate the different versions of the same apps unless they're deployed in their own JBOss instances.

Welcome to classpathhell, hopefully OSGi and JSR 291 will solve that, but until JBoss get good support for that...

I believe Spring dm server is already there in terms of OSGi support/integration.  Labourey commented that JBOSS 5 has some OSGi support but I'm still not sure exactly what it is and the extent of it...

OSGi (Open Services Gateway interface) is a specification maintained by the OSGi Alliance. It was founded in March 1999. One of the goals of OSGi is to reduce complexity by having much better modularity and deployment of libraries and services. The increased modularity primarily comes from a much more fine grained classloading mechanism compared to a standard JVM or Java EE container. Libraries and packages needed at runtime must be explicitly defined and even the version or version ranges required can be specified. Also, what interfaces or classes your library exports are also clearly defined. A library (JAR archive) in OSGi terminology is referred to as a bundle.

There are a few different open source OSGi runtime environments. Some are Apache Felix, Knopflerfish, and Equinox. You may know Equinox as being what the Eclipse IDE is built on. Any Eclipse plugin is actually an OSGi bundle, so Eclipse has very good OSGi development support.

The Spring dm Server is also an OSGi server and is actually built on top of Equinox. Although many customizations and enhancements have been done to make it easier to manage and deploy bundles. Some of the enhancements are customizations to make it easier to deploy Spring bundles and also for deploying web bundles. In fact, standard WARs can be deployed as they are to any web container. Web modules can also be deployed as a thin WAR that uses OSGi imports to resolve any JARs instead of having them embedded in /WEB-INF/lib and also a more OSGi like web solution which will be shown in the next basic example.

source: http://www.springindepth.com/book/sdms-basics.html

JSR 291 looks interesting (although there obviously needs to be a spec for JEE as well).  Rod Johnson is typically ahead of the pack in terms of technology and adoption.  It's tough to beat Spring, .NET and RoR!

[gonorrhea]

Francisco Peredo wrote on May 23, 2009 05:24:

Arbi Sookazian wrote on May 22, 2009 23:02:



So the key attribute here that is missing is the build number.  How is that generated?  Can we pull that number from the latest tag in SVN repo?  Or is it simply hard-coded in the build.xml?

You can use the BuildNumber ant task for that.

the buildnumber ant task merely increment the number by one.  not sure exactly what that means, in the of current build 1.0.0.0, but that's not smart/flexible enough for our needs.

[gonorrhea]

this looks much better! 

Here is how it can be used (suppose 1.3.1 is the latest version of ivy in the repository):

<ivy:buildnumber organisation="apache" module="ivy" />

will set 1.3.1 as revision, 1.3.2 as new revision, 1 as build number and 2 as new build number

only problem is how do you jump from 1.3.1 to 1.4.0?

this is one of the reasons we used the db table solution...

[kapitanpetko]

That's probably not going to solve your problem (unless you decide to switch to Maven), but the Maven build number plugin does this quite well.

You can have versions based on project.version, SVN revision number or anything you setup in a properties file.

[gonorrhea]

thanks for the tip.  There are already too many frameworks involved with Seam, so Maven is not a serious option for us (yet).  And from some of the comments I've read from DAllen on the JIRAs is that Maven is not ready for use with Seam (i.e. replace Ant with Maven completely).

But I find it interesting that nowhere in the Seam books or ref docs is this topic discussed...  It's a very standard software engineering problem.

[kapitanpetko]

Arbi Sookazian wrote on May 24, 2009 18:44:


thanks for the tip.  There are already too many frameworks involved with Seam, so Maven is not a serious option for us (yet).  And from some of the comments I've read from DAllen on the JIRAs is that Maven is not ready for use with Seam (i.e. replace Ant with Maven completely).

Well, I wouldn't say Maven is not ready for Seam. It does require a little more effort to get started with Maven, mostly getting SeamTest to work, anything else is pretty standard stuff. But it does pay off later, so it is worth considering IMHO, for new projects at least. Migrating an existing one might be too much trouble indeed.

But I find it interesting that nowhere in the Seam books or ref docs is this topic discussed...  It's a very standard software engineering problem.

It is standard stuff, but it is not Seam (or Spring or Struts) specific. Maybe if someone wrote a 'Best Practices for Java Web Apps' book or some such...

[gonorrhea]

Well, you could argue that to a certain extent it is seam-gen specific.  After all, reverse engineering your db schema to JPA entity classes is not really Seam specific (it's Hibernate Tools that does it).  But it's part of seam-gen.