So I did what we, engineers always do in this situation: run your own. Good news, it took just over an hour and I ended with a single very small file. It  can only variable substitution but that was enough for me. Here it is:

http://codebistro.googlecode.com/svn/trunk/misc/src/main/java/org/codebistro/util/BristleTemplate.java

The best part: it has no dependencies so you can just copy file into your project and template away.

Of course you can Maven just as well:

    <repositories>
        ...
        <repository>
            <id>codebistro-open</id>
            <name>codebistro-open repo</name>
            <layout>default</layout>
            <url>http://codebistro.googlecode.com/svn/repo/</url&gt;
        </repository>
        ...
    </repositories>
    ...
    <dependencies>
        ...
        <dependency>
            <groupId>org.codebistro.util</groupId>
            <artifactId>misc</artifactId>
            <version>1.0-SNAPSHOT</version>
        </dependency>
     <dependencies>

Microframeworks are popular these days. This thing doesn’t even qualify to be called micro- or even nano- but I got a feeling I am going to use Bristle template in the future…

I use my custom domain name Google Apps account as my primary email. I still have Google account and Google profile but I am not logged into this account by default.

So when I go to http://google.com/+ I get this dreaded error message:

Oops, you need a google profile to use this feature

I found a workaround to this problem. The solution requires that a) you have a “regular” Google Account (…@gmail.com) and b) this account should be enabled the “Sign in to multiple Google Accounts” feature (thanks Paul for the tip) :

1. Go to any profile page on Google plus:

2. Click on the Account -> Switch Accounts menu:

3. Select the Google Account (not the Google Apps account) or log into your Google Account:

Bingo! Your Google plus is now working!

This little rsync script can help moving all project files to a separate hierarchy so that you can manage them separately from your source tree:

#!/bin/sh

rsync -av \

–filter=’+ */’ \

–filter=’+ .classpath’ \

–filter=’+ .project’ \

–filter=’+ **/*.iml’ \

–filter=’+ .idea/***’ \

–filter=’- *’ \

–prune-empty-dirs $1 $2

Thanks Shane Meyers for the insight into rsync filter patterns.

[proguard] Reading library jar [/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/jsse.jar]
[proguard] Error: Can't read [proguard.ClassPathEntry@50502819] (No such file or directory)

With some help  from the Eric Lafortune, the ProGuard author, the solution was to put a link to the missing file to its “regular” place in Java libraries:

cd $JAVA_HOME/lib
sudo ln -s ../../Classes/classes.jar rt.jar
sudo ln -s ../../Classes/jsse.jar .

The downside is that you should do some manual stuff on each Mac you want to build on. If somebody has better solution I would love to know about it.

In military training long time ago, I and my fellow students were forced to do a lot of things that were illogical, redundant or  outright stupid. Sometimes our only explanation was “so the life wouldn’t seem sweet like honey”. It kind of made sense to make life intentionally hard in the army — it was supposed to be training after all. It seems that the Apple in this case was following the same logic: let’s spread runtime libraries all over the system so that the engineer’s life wouldn’t seem too sweet like honey. Anybody got better explanation, please let me know.

]]> http://codebistro.com/2010/07/18/proguard-and-runtime-libraries-on-mac-os-x/feed/ 1 codebistro http://codebistro.com/2010/03/25/adding-cacert-to-the-java-trusted-store/ http://codebistro.com/2010/03/25/adding-cacert-to-the-java-trusted-store/#comments Wed, 24 Mar 2010 16:07:47 +0000 codebistro http://codebistro.com/?p=27 ]]> http://www.cacert.org/ is a great way to easily create free SSL certificates for development work. In order to successfully connect from Java program using SSL to a server carrying a certificate issued by CACert you need to “bless” the certiticate, or make it trusted by your your local Java JRE installation.

Let’s first make sure we are in the lib/security subdirectory of the currently running JRE:

> cd $JDK_HOME\jre\lib\security

Then, download the certificate file to your local computer:

$JDK_HOME\jre\lib\security> wget http://www.cacert.org/certs/root.crt
--2010-03-16 09:24:40--  http://www.cacert.org/certs/root.crt
Resolving http://www.cacert.org... 213.154.225.245
Connecting to http://www.cacert.org|213.154.225.245|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2569 (2.5K) [application/x-x509-ca-cert]
Saving to: `root.crt'
100%[======================================>] 2,569       15.4K/s   in 0.2s
2010-03-16 09:24:41 (15.4 KB/s) - `root.crt' saved [2569/2569]

Now let’s import the certificate into the JRE keystore (note the password of the default JRE keystore — it’s different on different platforms):

$JDK_HOME\jre\lib\security> keytool -import -keystore cacerts 
-storepass changeit -alias cacert-root1 -trustcacerts -file root.crt
Owner: EMAILADDRESS=support@cacert.org, CN=CA Cert Signing Authority, OU=http://www.cacert.org, O=Root CA

Issuer: EMAILADDRESS=support@cacert.org, CN=CA Cert Signing Authority, OU=http:/
/www.cacert.org, O=Root CA
Serial number: 0
Valid from: Sun Mar 30 04:29:49 PST 2003 until: Tue Mar 29 05:29:49 PDT 2033
Certificate fingerprints:
MD5:  A6:1B:37:5E:39:0D:9C:36:54:EE:BD:20:31:46:1F:6B
SHA1: 13:5C:EC:36:F4:9C:B8:E9:3B:1A:B2:70:CD:80:88:46:76:CE:8F:33
Trust this certificate? [no]:  yes
Certificate was added to keystore

Now you are ready to start sending Java SSL requests to your server.

Molière

We have been doing AHAH for a few months and now I know! The thing definitely makes sense, especially as the app gets more complicated and every bit of code shaved off the client side saves us a bit of our lives.

The performance still requires investigation. For now I assume that transparent gzip compression can make HTML snippets just about as small as compressed JSON responses.