Other
Bounded beans in IntelliJ IDEA
Well, for some reason I lost my Intellij IDEA configuration. I had a nice live template to create a firePropertyChange statement. This is not as nice as the bound setter plugin for eclipse as it does not create the method but the methods body.
Basically create a new Live Template and set the name to something like “fpc”. The template is
firePropertyChange("$name$", $name$, this.$name$ = $name$);
and the variable definition for $name$ is variableOfType("Object"). Finally set the default value to “name” and you are ready to go. Let the IDE create a setter, remove the body, type fpc and hit tab. This will expand to the firePropertyChange statement and if you are lucky, the variable name is correct
Of course, the class has to be some sort of AbstractBean and provide a firePropertyChange
Get the current SVN revision number in from Ant
Another minor Problem I struggled with the last couple times I was updating one of my build scripts was resolving the current SVN revision number from within ant. Google points out a few solutions, but most of them require optional SVN tasks or do an exec. Someone (sorry, I would put a link if I could remember) came up with the simple solution of using the stored SVN information from the filesystem. So:
<loadfile property="svn.revision" srcFile="./.svn/entries">
<filterchain>
<headfilter lines="1" skip="3"/>
<deletecharacters chars="\n"/>
</filterchain>
</loadfile>
loads the current revision number into a property called svn.revision. I use this with svn 1.4 and 1.5 repositories and it works just fine.
Set JPA entities at runtime
We use JPA as persistence mechanism for EPoS. The JPA implementation for the next release will be EclipseLink and I was adding that over the weekend. One important thing: I don’t know the entity classes at compile time. That makes it impossible to add the class names to the persistence.xml directly. Somehow we need a way to specify the classes at runtime (well, at least at initialization time, when we boto up the EntityManagerFactory). That is something taht seems to be not part of the JPA spec for Java SE environments ( in Java EE, you can let it search the jar files for entity classes).
Ok, so we need a way to manipulate the content of the persistence.xml at runtime to add the class entries and I found way, hacking into the mechanism that reads the content of the persistence.xml.
Basically, what we do is, we occupy the stream that represents the file and manipulate it at runtime. To do so, we have to extend the initialization process, but, thanks to protected variables used by the EclipseLink team, this works without any manipulation of the EclipseLink source code. We have to extend some classes, to make it work, but thats it. And it turned out that the changes are rather minimal and the hack works straight forward. So, lets jump into the code and get things running. Still, keep in mind, we work on top of internal initialization code ! There is a good chance that this breaks with a new release, although I think it will be straight forward to keep things running…at least as long as the EclipseLink team sticks to protected access modifiers for some of their variables.
BeansBinding ELProperty as simple template engine
I just read an article about using adding EL support on your projects and I was looking for a nice alternative to Velocity anyways.
I know EL basics from BeansBinding, which I use in most of my UI projects. EL itself looks pretty interesting, but, well, sort of complicated. Even finding the proper jar files seems to be a problem, or at least “another of life’s obscure mysteries” and using EL for a simple search and replace example implies implementing some internals. I was looking for something that I can just use.
Luckily, the first comment mentions the ELProperty class from BeansBinding, and that jar is just a few mouse clicks away, so I thought I give it a try…and…well…it works
combine multiple jar files and remove signatures
I just came across a situation where I had to join multiple jar files and my own classes into one jar bundle. Ant comes in handy:
<jar destfile="${app.id}-${app.version}.jar"
index="true"
filesetmanifest="merge">
<fileset dir="${classes.dir}"/>
<zipgroupfileset dir="${lib.dir}" includes="*.jar" />
</jar>
This takes all the files in ${classes.dir}, packs them in a jar and add the content of all the jar files in ${lib.dir}. In this case, we merge multiple manifests, but this can be changed according to the jar task documentation.
› Continue reading
Add Copyright to Java Sources
Just found a nice Eclipse plugin that adds license information to a all the files (well, you can select them) in a project. You can specify the license, enter your own, customize the output …. nice !
Just reminds me, we had a java class that did that for QAlign 2 Panta Rei source code distribution.
Yeah, there it is, May 21, 2005 written in Michas old apartment in Barcelona while working on QAlign2.
ANT build.xml template
Just that I have it at one place. This is my ant build.xml template. It assumes a simple project structure:
src/ - all java soources in here lib/ devel/ - development libraries runtime/ - runtime libraries
If your project follows this struicture, you can get the following tasks out of the box:
Buildfile: build.xml Main targets: clean Clean compile Compile all source files compile-tests Compile all source files dist Build library and pack jar file dist-one Build library and pack jar file doc Create Javadoc html-reports Creates HTML from test reports test Run JUnit Tests Default target: dist
You can modify the properties to adapt different names or a different project structure. The script creates a target directory that contains the results.
Compiling and packing should work out of the box, but the test sections expects a junit and ant-junit jars in lib/devel. They can also be placed in one of Ants lib directories.
Packagesorter Sources
Here are the sources to the package sorter Eclipse plugin. The plugin is released under the EPL license and is packed as Eclipse Project. Unzip and import the directory into your Eclipse workspace.
Install Java 6 Update 10 on Ubuntu 8.04
I had to install Java 6 Update 10 on Ubuntu 8.04. The thing is straight forward if you do not want to integrate the new JVM into Ubuntus alternatives system (and do not need teh new Java Plugin in your browser). Download, install, modify your PATH, JAVA_HOME and JDK_HOME, done. Google helped to find this really good description of the process, including moving the JVM to /usr/lib/jvm, where Ubuntu expects the JVMs.
The tricky part is the integration into Ubuntus alternatives system. It provides an easy way to switch between VMs and is usable even by “non geek” users and update-java-alternatives will also switch your java browser plugin.
We have to have Java 6 installed from the Ubuntu repositories:
sudo apt-get install sun-java6-jdk
Now, follow Caspers first two steps to install the VM. Download Update 10 and execute the script
sh jdk-6u10-rc2-bin-b32-linux-amd64-12_sep_2008.bin
Move the directory to /usr/lib/jvm, where Ubuntu expects JVMs
sudo mv jdk1.6.0_10 java-6-sun-1.6.0.10
sudo mv jdk1.6.0_10/ /usr/lib/jvm
And create a symlink
cd /usr/lib/jvm
sudo ln -s java-6-sun-1.6.0.10 java-6.10-sun
The directory should look more or less like this
lrwxrwxrwx 1 root root 23 2008-10-07 19:01 java-1.5.0-sun -> java-1.5.0-sun-1.5.0.15
drwxr-xr-x 10 root root 4096 2008-10-08 11:34 java-1.5.0-sun-1.5.0.15
-rw-r--r-- 1 root root 2165 2008-03-26 02:28 .java-1.5.0-sun.jinfo
lrwxrwxrwx 1 root root 19 2008-10-08 12:21 java-6.10-sun -> java-6-sun-1.6.0.10
lrwxrwxrwx 1 root root 19 2008-10-07 19:00 java-6-sun -> java-6-sun-1.6.0.06
drwxr-xr-x 8 root root 4096 2008-10-08 11:35 java-6-sun-1.6.0.06
drwxr-xr-x 10 root root 4096 2008-10-08 11:40 java-6-sun-1.6.0.10
-rw-r--r-- 1 root root 2341 2008-10-08 11:47 .java-6-sun.jinfo
To integrate the new VM into the alternatives system, we use update-alternatives --install to get new alternatives and provide a .jinfo file used by update-java-alternatives. For simplicity, I (and the script) assume that you have Java 6 installed. We need the Java 6 .jinfo file as a template. Basically, we h clone and modify the file, such that all the links point to the appropriate directory. Well, that can be done with your favourite text editor. The ugly part is, you have to call udpate-alternatives --install for ALL the commands. That calls for a script
.
#!/usr/bin/perl
use strict;
# use this as template - we assume that you have java 6 installed
# its in the repo !
my $jvm_template="java-6-sun";
my $jvm_template_path="/usr/lib/jvm/java-6-sun";
# this is the new jvm
my $jvm_name="java-6-sun-1.6.0.10";
my $jvm_alias="java-6.10-sun";
my $jvm_path="/usr/lib/jvm/java-6.10-sun";
my $jvm_priority=64;
my $jvm_section="non-free";
open(JINFO_OUT, ">/usr/lib/jvm/.$jvm_alias.jinfo") or die "Can not write jinfo file !";
#write header
print JINFO_OUT "name=$jvm_name\n";
print JINFO_OUT "alias=$jvm_alias\n";
print JINFO_OUT "priority=$jvm_priority\n";
print JINFO_OUT "section=$jvm_section\n\n";
my @lines = ();
open(IN, "/usr/lib/jvm/.$jvm_template.jinfo") or die "Can note read jinfo template!";
@lines = <IN>;
close(IN);
my @new_config = ();
foreach(@lines){
if($_=~ /$jvm_template_path/){
chomp($_);
$_ =~ s/$jvm_template_path/$jvm_path/;
push(@new_config, $_);
print JINFO_OUT "$_\n";
}
}
close(JINFO_OUT);
foreach(@new_config){
my @split = split(' ', $_);
system("update-alternatives --install /usr/bin/@split[1] @split[1] @split[2] $jvm_priority");
}
Download the script and execute it (with sudo/as root – we have to write to /usr/lib/jvm) after you have moved the update 10 installation to /usr/lib/jvm/java-6-sun-1.6.0.10 and created the symlink to java-6.10-sun as described above. (The script is quick and dirty. The names are defined in the first lines. If you have used other directory/alias names, you have to modify the script).
sudo perl create-jvm-alternative-6.10.pl
This generates a .jinfo file in /usr/lib/jvm and it calls update-alternatives --install for all the things mentioned in the template .jinfo. The update-alternatives takes a generic name as first argument (thanks Jonathan – I should read man pages more often). This is created as a symlink pointing to the actual name in /etc/alternatives. /etc/alternatives then points to the currently chosen alternative. SO, for example, at some point the script calls:
update-alternatives --install /usr/bin/java java /usr/lib/jvm/java-6.10/bin/java
This creates two symlinks
/usr/bin/java -> /etc/alternatives/java
/etc/alternatives/java -> /usr/lib/jvm/java-6.10/bin/java
The latter might already exist and point to some java alternative (i.e. java v1.5). As far as I’ve seen this is not overwritten. The latter symlink is the one that is actually changed when you switch alternatives.
When everything is done, you should get something like:
thasso@antef:~> update-java-alternatives -l
java-1.5.0-sun 53 /usr/lib/jvm/java-1.5.0-sun
java-6.10-sun 64 /usr/lib/jvm/java-6.10-sun
java-6-sun 63 /usr/lib/jvm/java-6-sun
