Great news today as GlassFish v3 Prelude is out!
You can grab it now from https://glassfish.dev.java.net/downloads/v3-prelude.html.
This preview release is very appealing. GlassFish is becoming increasingly popular, and this release will certainly contribute to this trend.
BTW expect me to release a Prelude installer based on IzPack soon 
You may have read from my recent posts that I have started to play with Git in conjunction with Subversion for working on IzPack.
Having a distributed SCM tool (here Git) that is able to work with a central repository (here SVN) is a huge advantage as it gives you more flexibility workflow-wise. Think branches, commit as you go, interact with non-commiters, etc.
I am however no fanboy: I still see value in Subversion and its centralized model. Much like I advocate polyglot programming, I advocate polyglot SCM 
If you are not convinced, try something like Mercurial for yourself: it has many merits such as fitting the requirements of a large majority of projects, or being way easier to use than Git.
After a few weeks of practice, I have now my mind clear on which use-cases fit better than others for Git or Subversion. This is biased to the way I work on IzPack, but I suppose that this applies well to most other projects.
Do you have similar feelings with both tools used in a project?
I have just refreshed the Wordpress installation of this blog.
First of all I must admit that I am tired of having to upgrade Wordpress so often. They should really think about squashing security leaks for real so as to ease it off.
The most visible change is that I have switched to the default Wordpress theme. I really find it clean and smooth, so who cares?
I have also integrated reCAPTCHA for posting comments. Even with Akismet, I am still getting lots of spam comments that get in and I am really tired of removing them everyday. Sorry guys for the inconvenience, but I assure you that reCAPTCHA is not too painful
Many people have been offering their IzPack-based installers through Java Web Start (one well-know example is JBoss AS). This can be handy at times: you just click on a link/button on a webpage then Java Web Start downloads the installer and runs it for you. No need to download, double-click on the JAR, etc.
Offering an installer through Java Web Start is not very complicated, yet you may not be familiar with how it works. Especially, you may not know how to create that JNLP file that makes it all possible.
I have created a tool, now in the project Subversion trunk, that I called izpack2jnlp. It is written in Python. All you need to do is to pass it a bunch of arguments and it will create the JNLP file for you.
Once this is done, you only have to sign your installer JAR file then upload the files (installer JAR + JNLP file) to the right place so that the URLs match the codebase argument that you gave to izpack2jnlp.
You can already grab and test this tool from:
Do not hesitate to propose enhancements
2008/10/27: I have removed my vendor-svn-trunk branches on Github. Indeed, I realized that I have not been using them properly. In the future, I will always consider master branches as the exact copies of Subversion trunks, i.e., new commits in master will appear after Subversion commits (mines or not) have been fetched locally.
These instructions will be helpful to the IzPack developers, but you can certainly adapt them easily for your own project.
The idea is to use Git, a decentralized SCM tool along with Subversion. This is getting quite common to mix both tools: Subversion hosts the “official” source code while developers and external contributors may collaborate with more flexibility in Git.
Git plays nice with Subversion. One can easily “clone” a Subversion repository into a Git one. This is however a lengthy process if your project has accumulated many revisions. I did that once for the IzPack Subversion trunk, then published it to Github.
Someone that has commit access to the project in Subversion can easily use Git as well. Instead of converting the whole repository again, there is a simpler solution. I use that on other machines too when I want to work on IzPack using both Git and Subversion.
First, clone the trunk with only a few of the latest revisions. Unless you really have to dig far in the past, you won’t need much of those revisions anyway
git svn clone --username=jponge -r 2300:HEAD -T https://svn.codehaus.org/izpack/izpack-src/trunk izpack.git
It is then easy to check that I have a master branch with a special trunk branch that is handled by git-svn:
jponge:izpack.git julien$ git branch -a * master git-svn
I can then easily add my GitHub remote branches. Use a different clone URL in your case: either the read-only one of my GitHub repository, or your very own fork of it.
git remote add origin git@github.com:jponge/izpack.git git fetch warning: no common commits remote: Counting objects: 17652, done. remote: Compressing objects: 100% (4214/4214), done. remote: Total 17652 (delta 11961), reused 17611 (delta 11942) Receiving objects: 100% (17652/17652), 14.49 MiB | 265 KiB/s, done. Resolving deltas: 100% (11961/11961), done. From git@github.com:jponge/izpack * [new branch] master -> origin/master * [new branch] vendor-svn-trunk -> origin/vendor-svn-trunk * [new branch] with-git-submodules -> origin/with-git-submodules jponge:izpack.git julien$ git branch -a * master origin/master origin/vendor-svn-trunk origin/with-git-submodules trunk
This fetches more data as my GitHub repository contains the whole IzPack history that I had converted a while back from Subversion.
You can see that I work with a few branches:
We need to reset our local master branch to origin/master as git-svn has put it on trunk:
git reset --hard origin/master HEAD is now at c23f4e5 Merge branch 'local-trunk'
We can now create a few local branches:
git checkout -b local-trunk trunk git checkout -b with-git-submodules origin/with-git-submodules git checkout master
which gives:
jponge:izpack.git julien$ git branch -a local-trunk * master with-git-submodules origin/master origin/vendor-svn-trunk origin/with-git-submodules trunk
That’s it, you can work with Git. Getting updates from SVN is easy (git svn fetch). It is easy to push back those updates from trunk to origin/vendor-svn-trunk. It is also easy to commit using git svn dcommit.
Git + SVN gives a really great flexibility for developing new features and collaborating with non-developers. Indeed, I can ultimately push back the work from Git to Subversion. I still use Subversion directly for many tasks such as committing a patch, but for new features working with Git is really appealing
