Quickstart flex development with this maven archetype

Have you considered starting some flex development, but haven´t found out where to start? Or are you already flex'ing but could use some easy way to quickstart new flex projects in java?

I have created a maven archetype called maven-archetype-flex and distributed it to ibiblio for all to use.
It will quickly get you up and running.

Here is how you do it:

1. Download flex sdk
Download the flex sdk from adobe, if you haven't got it already.

1b. Minor change to flex-config.xml
You have to uncomment the following in your flex-config.xml located in:

${flex.home}/frameworks/flex-config.xml

<local-fonts-snapshot>localFonts.ser<local-fonts-snapshot>

Otherwise the compiler will complain as Matt mentions in his comment.

2. Create flex project
Running the following maven command will create a flex project called my-flex having groupId my.group. Feel free you change these to what ever you like:

mvn archetype:create
-DarchetypeArtifactId=maven-archetype-flex
-DarchetypeVersion=1.0
-DarchetypeGroupId=dk.jacobve.maven.archetypes
-DgroupId=my.group
-DartifactId=my-flex
-DpackageName=

Note: it is important that you remember the -DpackageName= as the Main.mxml flex file in the archetype is to be kept in the root of your source dir and not in some subpackage.

3. Set flex.home property
In the newly created project pom.xml you should change the flex.home property to fit your flex.home path.

4. Build flex project
Now you are ready to build the flex project:

mvn install

Running this command inside your project will build the project and create a swf file in the target directory.

Viola! You have just created a simple flash application ready to use.

Where to go from here
To see the result of the work you can do one of the following things:

• Open the flash file with your favorite browser.
  
• Download the standalone player for your operating system ().
• Deploy the swf file to a webserver. Maybe you can get inspiration on how to do it from this maven flex template.
  

Flex maven template - getting started

In Per´s lession 1 of his flex development tutorial he showed us a build setup - it is a bit outdated by now as the israfil plugin moved to google code and the sateh repository doesn't exist anymore. It also only contained the flex module and no war sample showing how easy it is to deploy the flex application.

I took the liberty to create my own template consisting of a multimodule build:

• Flex module - looking prettymuch the same as Per´s.
• War module - depending on the flex module wrapping the swf file into a war ready to deploy.

I would have created a maven archetype, but considering mavens lack of support for archetypes containing multimodules I just created a zip.

I find the template useful when starting a flexproject from scratch and maybe you will too?

Download
Download the flex-template

For more information about the israfil plugin click here

Sharing flex code examples

Developing flash front ends with flex is really getting to me.
I don't have Flex Builder but find no problem with developing using another IDE combined with maven and the israfil mojo.

From time to time I blog about some nifty actionscript 3/flex code but I am missing a simple way to distribute the sourcecode.
Unfortunately my IDE - Intellij IDEA - doesn't contain a feature making it easy to distribute the flex sample code, neither have I found a maven plugin capable of packaging the sourcecode for distribution.

Adobe added the ViewSource capable of linking to some arbitrary URL where the source is located.

import com.adobe.viewsource.ViewSource;
...
ViewSource.addMeneuItem(this,"srcview/index.html");

But then again you have to have the source code distributed :-)

I am considering developing a maven plugin that can do the job, but it would be waste of time if a solution is somewhere "out there".

So please let me know!

A badly packaged project will break builds!

I have stumpled across many comments on different blogs bashing maven for being a bad build tool. To me it seems that an era of "hate maven" is rising and many people seems to just blindfolded follow the horde of maven bashers.

It seems to me that people tend to forget what maven brings to a project.

• Convention above configuration.
• Dependency management.
• A bunch of default plugins ready to be used. (You can argue the quality of all opensource plugins, but I really think it is getting better)

A thing like dependency management is one of the greatest benefits. Luckily I have forgot the old days where precious time was spend looking for dependencies need by other dependencies.

Although maven provides many benefits I ran into one of the things that one could call a bad side effect of using maven and its transitive dependency management.

The springframework is distributed in two different ways.
As a single artifact containing the complete spring distribution and as a much more fine grained distribution where each artifact contains a logical spring module.
As it all seems fine and interface21 probably think they are pleasing the broader audience by providing the different distributions, it brings a bigger problem to the surface.

By providing the same code in different artifacts you introduces the risk of a project to unintentionally depend on the same software in different versions.

In my case just adding the acegi 1.0.4 to my maven pom.xml broke our build - and I did not even configure or use any of the acegi code!

Ofcourse I wasn't late to blame maven. As the problem showed up by just modifying my pom.xml the problem couldn't be blamed on anybody else but maven.

Some exercises with the -X option shed some light on my problem:
Acegi 1.0.4 depend on the fine grained distributions of spring 2.0.4 modules, but as it happens I already had a dependency to the full spring 2.0.5 artifact. Dependency resolution interprets the to versions of the same software as different artifacts - and if you stick strictly to the maven dependency resolution rules they sure are different!

A dependency is defined uniquely as follows:
<groupid><artifactId><version><package>

As the version changes, maven takes care of using the latest version. But with different artifactnames containing the same code, you are most likely leaving your users of your library with a classloading issue just around the corner.

Hence the cause of the problem was lying outside maven.

Now you would probably tell me that I should only use the fine grained spring dependencies - but I was probably lazy and sure others out there are lazy too.

My experience sums up to the following rules of thumb:

1. Apply DRY to your artifacts distribution.
   If you repeat yourself in your artifacts you introduce risks (not the same type of risk though) as if you repeat your code.
   
2. Choose your groupId wisely and do not change it again - ever.
   

After blaming Spring I can tell that Spring isn't the only one to break dependency rules of thumb.
Ehcache has changed its groupId between version 1.2.3 to 1.2.4 and bingo! You have to different artifacts from a dependency resolution point of view.

Conclusion
Even with the quirks I just described I still think maven dependency management it is fare better than the good old plain Ant days!

Hints
If you suspect that you have run the same problem as I did, I suggest you run maven with the -X option as it prints the complete dependency resolution tree. From there you can find what transitive dependencies to exclude.
If you prefer Ant you should take look at the dependency management tool Ivy, but that subject is worth its own blogpost...

quicky: xml schema validation using dom4j

I believe I have spend to much time with xml schema validation using dom4j, considering what I think should be a trival operation.
I was not capable of finding the howto on this subject, so I will provide my own. Mosty as a note to myself the next time I have to do schema validation.

public Document parseXMl(String xml) throws Exception {
  URL resource = getClass().getResource("/my-schema.xsd");
  SAXReader reader = new SAXReader(true);
  reader.setFeature("http://apache.org/xml/features/validation/schema", true);
  reader.setProperty("http://java.sun.com/xml/jaxp/properties/schemaLanguage", "http://www.w3.org/2001/XMLSchema");
  reader.setProperty("http://java.sun.com/xml/jaxp/properties/schemaSource", new File(resource.getFile()));
  reader.setErrorHandler(new ErrorHandlerImpl());
  InputSource source = new InputSource(new StringReader(xml));
  source.setEncoding("UTF-8");
  return reader.read(source);
}

Centralize surefire reports from multiple maven modules

For a long time I have been cursing the maven-site-plugin for not giving me the opportunity to assemble and centralize all surefire reports from my submodules.

One could argue (and I agree) that a benefit of using maven is that it urges you to split your code into logical reusable artifacts (submodules). But at the same time as you don't have the tool to combine reports from the submodules you could easily be loosing the big picture of any errors and failures in your testcases.

Up until now I have either ignored the fact that I couldn't get the big picture (yes, I'm ashamed :-) or implemented a solution using the maven-antrun-plugin and a simple Ant script.
But then my colleague Per showed me the fairly new dashboard-maven-plugin from codehaus and that does exactly what I have been missing for quite some time.

As they say: "The basic purpose of "Maven Dashboard Report Plugin" is to centralize and share all quality informations generated by other Maven report plugins..."

Finally, home grown Ant solutions seem to be history!

Still thinking on this project I worked on last year together with my good friend and colleague Claus, that could benefit from moving to the dashboard-plugin and throw away the ant solution we implemented.

Keep learning without your computer

My vacation is moving closer and closer and I am actually looking forward to the annual three weeks completely offline.

As the past two years we are driving to the southern Europe which means I am going to spend many ours behind the wheel.
Time that I usually spend listening to music on the local radio.
As podcasting is getting more and more popular I thought it could be worth looking through the internet for interesting subjects.

I found a couple that I will definitely download:
- Google
- Ajaxian
- Devcasting

Many others are available but I am not sure about the quality.
So let me know if you can recommend any other podcast.

Now only one thing stands between me and my offline knowledge transfer - my girlfriend!
Still thinking on how I can convince her that technology podcasting is so much more interesting for her than listening to the radio :-)

Tip: How to depend on non maven artifacts in a maven build

Have you ever wanted to depend on some jar file that is not located in any public maven repository you probably ended up copying the dependency to your local repository and creating pom and md5 files by your self. Maybe you didn't even create the md5 files as it is not necessary and 'only' generates a warning in your maven build lifecycle.

Instead of doing all the hard work, you could use the install-file goal maven-install-plugin.

The install-file goal installs the artifact into your local repository. It can aslo create the nessesary pom.xml and checksum files.

A simple example of use:

$ mvn install:install-file -Dfile=pzfilereader-3.0.0.jar -DgroupId=net.sf.flatpack -DartifactId=pzfilereader -Dversion=3.0.0 -Dpackaging=jar -DgeneratePom=true -DcreateChecksum=true


The preferred csv parser for java?

My project needs to parse a csv file.
Of course I could write "yet-another-csv-parser", but this time I looked a bit further - past my own code to see if someone else had created the preferred csv java api.

My requirements seemed fair:

• Open source:
• I would like to see the code and have the ability to extend where needed
• If the code is available from a maven repository it is easy to download and add to my favorite IDE (intellij idea)
• Distributed to ibiblio with sourcecode would be great as it eases my work even more.
  

• Some kind of error reporting
  It would be nice if the parser could report a more specific error than just an IOException with now details. It would be nice if the error could tell something about what line that couldn't be parsed.
  

I found a couple of api's that I took a closer look at:

http://www.csvreader.com/
- Seemed easy to use, but not available from ibiblio (or any other repository I could find)
- Binary was available from sourceforge as was the sourcecode
- No error reporting besides IOException

http://www.mvnrepository.com/artifact/genjava/gj-csv
- Binary and source available from ibiblio.
- No error reporting besides IOException

http://www.mvnrepository.com/artifact/net.sf.opencsv/opencsv
- Only binary available from ibiblio.
- No error reporting besides IOException

Looked at some other apis as well but my general observation was that non of the api's had a focus on error reporting or validation of the document.

Why doesn't the java community have a preferred api for csv parsing?
One explanation could be that every project implements its own as parsing a csv file seems as a trivial operation.
Another explanation could be that this kind of work suffer from the Not invented here syndrome? :-)

Please let me know that I am missing the implementation - it simply must be out there.

Tapestry Bayeux 2.0.0 released - Improved download an image streaming functionality

I have just released the final version of Tapestry Bayeux 2.0.0.

Maven:
As with 2.0.0-beta2 the new 2.0.0 will be available from ibiblio in a couple of days.

Then you will be able to depend on Bayeux by adding the following dependency snippet to your pom.xml

<dependency>
 <groupId>com.nordija.tapestry.bayeux</groupId>
 <artifactId>tapestry-bayeux</artifactId>
 <version>2.0.0</version>
</dependency>

Tapestry version:
The last version 2.0.0-snapshot was compiled and tested against Tapestry 4.1, but because of some issues with Tapestry 4.1 and Java 1.4 I decided to upgrade to Tapestry 4.1.1.

New Features:
A few extra features has been added since 2.0.0 beta-2:

• StreamLink: A updated an renamed version of the DownloadLink. This StreamLink works together with the StreamService to get access to a StreamResource defined by the user.
  The StreamService is capable of streaming all kinds of data, hence the StreamLink is useful when a tapestry application is to provide some kind of download facility.
  
• StreamAsset: As the StreamLink this asset works together with the StreamService. The StreamAsset is useful for streaming images that is not a static asset.
  That could be streaming of a JFreeChart (something that Bayeux provides special StreamResource implementations for)
• RequiredValidationDelegate: A simple extension of the default ValidationDelegate provided by tapestry. The RequiredValidationDelegate uses css instead of hard coded font color values.
  But the most nifty feature is the integration with the input fields and any associated RequiredValidator. Every input field with an requiredvalidator is marked with a *, hence you don't have to keep your required fields in sync with your validators.
  

Enjoy!

Flex: ISO-8859-1 vs. UTF-8

Hint:
In a flex/flash project we encoded our files using iso-8859-1 encoding resulting in the danish characters like æ, ø etc. not being encoded correct.

The adobe flex compiler seems to interpret all files not containing a Byte Order Mark (BOM) as utf-8 even though we specified the -compiler.actionscript-file-encoding option.
Changing our files to utf-8 encoding solved the problem and no -compiler.actionscript-file-encoding option was needed.

And luckily for that as the israfil maven flex plugin that we use doesn't support the -compiler.actionscript-file-encoding option in the latest available version (1.0).

Multiple persistence.xml files and spring

Today I struggled a bit with multiple persistence.xml files using Spring, JPA (duh).

I had two jar's each containing mapped domain objects and an associated persistence.xml file.

Unfortunately the JPA specification doesn't say anything about how to handle multiple persistence.xml files hence no merging is done by default.

Some searching led me to a jira issue concerning this that Juergen Hoeller have closed for spring 2.0.4.
We have just implemented our own PersistenceUnitManager capable of collecting multiple persistence.xml files and it works great!

Java code:

package com.foobar.spring;

public class MyPersistenceUnitManager extends DefaultPersistenceUnitManager {

  protected void postProcessPersistenceUnitInfo(MutablePersistenceUnitInfo pui) {
    super.postProcessPersistenceUnitInfo(pui);
    pui.addJarFileUrl(pui.getPersistenceUnitRootUrl());

    MutablePersistenceUnitInfo oldPui = getPersistenceUnitInfo(pui.getPersistenceUnitName());
    if (oldPui != null) {
      List urls = oldPui.getJarFileUrls();
      for (URL url : urls) {
        pui.addJarFileUrl(url);
      }
    }
  }
}

And in your spring configuration add the following (Most likely called applicationContext.xml):

<bean id="persistenceUnitManager" class="com.foobar.spring.MyPersistenceUnitManager">
  <property name="persistenceXmlLocations">
    <list>
      <value>classpath*:META-INF/persistence.xml</value>
    </list>
  </property>
  <property name="defaultDataSource" ref="dataSource"/>
</bean>

<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
  <property name="dataSource" ref="dataSource" />
  <property name="persistenceUnitManager" ref="persistenceUnitManager" />
...

Tapestry Bayeux 2.0.0-beta2 available from ibiblio

Tapestry Bayeux 2.0.0-beta2 (binary and sources) is now available from the central maven repository.

To use the component library just add the following dependency to your pom.xml:

<dependency>
  <groupId>com.nordija.tapestry.bayeux</groupId>
  <artifactId>tapestry-bayeux</artifactId>
  <version>2.0.0-beta2</version>
</dependency>

2.0.0-beta2 is targetting tapestry 4.1 but because of an issue with tapestry 4.1 and java 1.4 I have mentioned before, the final release of 2.0.0 will target tapestry 4.1.1.

Tapestry Bayeux 2.0.0 is also intended to have some asset or component that integrate with JFreeChart - making it easier to stream charts.

Tapestry 4.1 jdk issues - fixed in 4.1.1

Lately I have spend some time investigating a Tapestry and Java 1.4 issue.
It evolved into a jira issue and yesterday Jesse Kuhnert closed the jira as the issue is fixed in 4.1.2-snapshot.
Actually it is already fixed in 4.1.1 as I tried my little testcase against 4.1.1 this morning.

Discovering this will most likely result in Bayeux targeting tapestry 4.1.1 in the final 2.0.0 release comming up.

Also I hope the changes report will tell that the issue has been fixed when a new site is updated. At the current time of writing the changes report states that the 4.1.1 is unreleased although the binary can be downloaded from the central maven repository.

Jira issue on Tapestry 4.1 not being java 1.4 compatible

I haven't been able to find an answer my question from yesterday - whether or not Tapestry 4.1 should be java 1.4 compatible.

After writing in the tapestry mailing list I was urged to create a Jira issue.
So I did and the issue can be found in JIRA: TAPESTRY-1520.
I have also created a small sample testcase demonstrating the problem.

For those interested the sample application can be found here and a log showing what I did can be seen here:

jeyben@vilfortpark /cygdrive/c/projects/sandbox/tapestry-jira
$ echo $JAVA_HOME
C:\jdk\j2sdk1.4.2_10

jeyben@vilfortpark /cygdrive/c/projects/sandbox/tapestry-jira
$ mvn
[INFO] Scanning for projects...
[INFO] ----------------------------------------------------------------------------
[INFO] Building Prove JDK issue
[INFO] task-segment: [install]
[INFO] ----------------------------------------------------------------------------
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 1 source file to c:\projects\sandbox\tapestry-jira\target\test-classes
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Compilation failure
c:\projects\sandbox\tapestry-jira\src\test\java\org\apache\tapestry\components\TestJdkIssue.java:[4,-1] cannot access org.apache.tapestry.engine.RequestCycle
bad class file: C:\Documents and Settings\jeyben\.m2\repository\org\apache\tapestry\tapestry-framework\4.1\tapestry-framework-4.1.jar(org/apache/tapestry/engine/RequestCycle.class)
class file has wrong version 49.0, should be 48.0



c:\projects\sandbox\tapestry-jira\src\test\java\org\apache\tapestry\components\TestJdkIssue.java:[4,-1] cannot access org.apache.tapestry.engine.RequestCycle
bad class file: C:\Documents and Settings\jeyben\.m2\repository\org\apache\tapestry\tapestry-framework\4.1\tapestry-framework-4.1.jar(org/apache/tapestry/engine/RequestCycle.class)
class file has wrong version 49.0, should be 48.0


[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2 seconds
[INFO] Finished at: Sat May 26 17:49:22 CEST 2007
[INFO] Final Memory: 6M/14M
[INFO] ------------------------------------------------------------------------

jeyben@vilfortpark /cygdrive/c/projects/sandbox/tapestry-jira
$ export JAVA_HOME=C:\\jdk\\jdk1.5.0_06

jeyben@vilfortpark /cygdrive/c/projects/sandbox/tapestry-jira
$ mvn
[INFO] Scanning for projects...
[INFO] ----------------------------------------------------------------------------
[INFO] Building Prove JDK issue
[INFO] task-segment: [install]
[INFO] ----------------------------------------------------------------------------
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 1 source file to c:\projects\sandbox\tapestry-jira\target\test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory: c:\projects\sandbox\tapestry-jira\target\surefire-reports

-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running org.apache.tapestry.components.TestJdkIssue
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.063 sec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

[INFO] [jar:jar]
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO] Building jar: c:\projects\sandbox\tapestry-jira\target\tapestry-jdk-issue-1.0.0-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing c:\projects\sandbox\tapestry-jira\target\tapestry-jdk-issue-1.0.0-SNAPSHOT.jar to C:\Documents and Settings\jeyben\.m2\repository\com\nordija\tapestry\issue\tapestry-jdk-issue\1.0.0-SNAPSHOT\tapestry-jdk-issue-1.0.0-SNAPSHOT.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3 seconds
[INFO] Finished at: Sat May 26 17:50:05 CEST 2007
[INFO] Final Memory: 8M/14M
[INFO] ------------------------------------------------------------------------


Shed light on a classloading mystery

Have you ever struggled with class loading problems like java.lang.NoClassDefFoundError or having the java compiler or jre telling you that a class signature is different than you expect it to be?
The latter is often because the class you thought was classloaded actually was loaded from another location but in a different version than you expected.

To shed light on the classloading mystery I have used the following bash command with success:

$ for i in `find . -name *.jar`; do echo $i; jar tvf $i | grep [a name of a class]; done

A quick explanation:
- for i in `find . -name *.jar`; It iterates through all found jar files in the actual directory and any subdirectory.
- echo $i; Then it echoes the path and filename for any jar file it finds.
- jar tvf $i | grep [a name of a class]; Executing a jar tvf *(testing a jar unpack) and piping it into a grep will print any line containing the text you search for.

Simple example where I locate all Tapestry BasePage classes (and sourcefiles) in my maven 2 repository:

jeyben@vilfortpark ~/.m2/repository/org/apache/tapestry
$ ls -l
total 0
drwx------+ 3 jeyben Ingen 0 May 12 20:56 tapestry-annotations
drwx------+ 3 jeyben Ingen 0 May 12 20:56 tapestry-contrib
drwx------+ 3 jeyben Ingen 0 May 12 20:57 tapestry-core
drwx------+ 4 jeyben Ingen 0 May 12 20:54 tapestry-framework
drwx------+ 3 jeyben Ingen 0 May 12 20:57 tapestry-ioc
drwx------+ 5 jeyben Ingen 0 May 12 20:57 tapestry-project

jeyben@vilfortpark ~/.m2/repository/org/apache/tapestry
$ for i in `find . -name *.jar`; do echo $i; jar tvf $i | grep BasePage; done
./tapestry-annotations/4.1.1/tapestry-annotations-4.1.1.jar
./tapestry-contrib/4.1.1/tapestry-contrib-4.1.1.jar
./tapestry-core/5.0.1/tapestry-core-5.0.1.jar
./tapestry-framework/4.1/tapestry-framework-4.1-sources.jar
1172 Fri Jul 07 02:04:04     2006 org/apache/tapestry/html/BasePage.java
./tapestry-framework/4.1/tapestry-framework-4.1.jar
540 Fri Jul 28 14:33:34     2006 org/apache/tapestry/html/BasePage.class
./tapestry-framework/4.1.1/tapestry-framework-4.1.1-sources.jar
1181 Fri Nov 10 13:26:26     2006 org/apache/tapestry/html/BasePage.java
./tapestry-framework/4.1.1/tapestry-framework-4.1.1.jar
540 Sun Dec 17 02:36:28     2006 org/apache/tapestry/html/BasePage.class

Tapestry 4.1 and jdk issues

I am developing a couple of components for Tapestry 4.1. They are meant to go into the final release of Tapestry Bayeux 2.0.0.
But I am having some difficulties getting a clear answer whether or not Tapestry 4.1 is java 1.4 compatible.
Just up until now I thought it was because tapestry 4.0 was and haven't seen any notes saying different about the 4.1 release. But now I am in doubt because I am having trouble executing on of my a testcases compiled by java 1.4.
I keep getting:

java.lang.UnsupportedClassVersionError:
org/apache/tapestry/markup/MarkupFilter (Unsupported major.minor version 49.0)

The error indicate that tapestry 4.1 has been compiled using java 5 and I am trying to compile and execute my test using java 1.4.

To further strengthen my theory I stumbled across the following code in the tap 4.1 source which uses autoboxing, hence can only be compiled by java 5.

org.apache.tapestry.dojo.form.Autocompleter
from line 268:
/**
* {@inheritDoc}
*/
public boolean isAsync()
{
return Boolean.TRUE;
}

If I have to compile using tapestry 4.1, is it correct that my only solution is to go with java 5 and no longer support java 1.4 runtimes?

I did some google searching: site:tapestry.apache.org/tapestry4.1 jdk but I only managed to find the following phrase on the page describing the upgrade from 3.0 to 4.0.
"Part of the transition to Tapestry 4.0, and targetting (in a later release) a minimum JDK of 1.5,..."
A later release seems to be Tapestry 4.1!

I miss a clear statement telling what java version tapestry is compiled by and what runtimes tapestry 4.1 supports.

You are more than welcome to enlighten me if you know the answer.

Bayeux is now tapestry 4.1 compatible

I am a developer of Tapestry Bayeux and is proud to announce the release of Tapestry Bayeux 2.0.0-beta-2 (see: changelog).

The reason why I have decided to name the release beta-2 is because the flow component available in bayeux 1.4.0 isn't included in this release. But that is the only reason and the rest of the components is stable.

What is bayeux?
Tapestry Bayeux is a open source component library for Tapestry and was released for the first time back in 2004.

Bayeux contains various components primarily developed for use in projects that Nordija is involved in. But since our first release we have had numerous downloads and we know for sure that tapestry jumpstart 1.2 uses the "do it once" components.

Actually it was Geoff Callender - the developer of tapestry jumpstart - that inspired me to upgrade tapestry bayeux.

When we first released Bayeux, tapestry 3.0 had only been stable for about half a year.
Since then tapestry has evolved rapidly and the latest stable release at the current time of writing is 4.1.1.
In hope to fit as many active tapestry projects as possible, we have upgraded Bayeux to tapestry 4.1.

Your past will always haunt you...

Recently I was contacted by Geoff Callender, the guy behind the Tapestry Jumpstart application.

He was working on the next Jumpstart version (1.2), that should contain a solution to the famous redirect-after-post paradigm.
As any other developer he must have used Google in his search for inspirationto such a solution and Google must have led him to Tapestry Bayeux.

Bayeux is a Tapestry Component Library containing a small set of components that a couple of my colleagues and I have developed a long time ago - back in the time were Tapestry 3 was on anybodies lips.

Geoff was interested in in the "do it once" components that prevents the user from activating more than one listener by the use of some Javascript. They should be a part of his solution to the previous mentioned redirect-after-post paradigm.

But those components was only Tap 3 compatible, so Geoff had to convert the components to Tap 4 him self if he would like to use this approach in his solution.

And so he did!
I tried to convince him to contribute the source back to Bayeux by giving him developer privileges but some how that wasn't tempting enough. :-)

So now I am "stuck" with the task of bringing Bayeux up to the latest stable version of tapestry - which is 4.1.1 at the current time of writing.
Its funny how software you developed as a part of a solution for some client back in the ages can haunt you down and for a split second make you think "why did I ever make it open-source" :-)


Just started the upgrade of Bayeux made me realize that software development has moved on since then...
CVS > SVN
Maven 1 > Maven 2
etc...

Just more work to be done... :-)