Bad news for Netbeans?

The latest document from Oracle on the merger doesn’t look that good for Netbeans. Glassfish will get resources and be more integrated with Weblogic. MySQL will get more resources. Solaris, Sparc, storage too.

But for Netbeans:

“As such, NetBeans is expected to provide an additional open
source option”. No commitment.

More at Adam Bien.

Docbook, Maven, SVG and fonts

I wrote in my last post about using Maven to build good-looking and maintainable documentation. I had issues with raster images getting rendered in the wrong resolution with Apache FOP. I tried RenderX XEP and it rendered in the correct resolution, but the images still look a bit blurred in the resulting PDF. Also the personal edition adds a footer on every page. Side note: I don’t mind paying for software, but it is always a hassle with license files and registrations. The benefits must be big for me to include a tool like this in my toolbox.

SVG

Since raster images was problematic I thought about using a vector format instead. I used OmniGraffle Professional to generate SVG illustrations. OmniGraffle is a really nice program. This worked pretty well with FOP (it is using Apache Batik behind the scene, I think). But I could not get font rendering to work inside SVG. It is replacing the fonts I used with Times.

I have set up FOP to use some fonts I like. It looks like this in the pom.xml:

<font>
  <name>FrutigerLinotype-Roman</name>
  <style>normal</style>
  <weight>normal</weight>
  <embedFile>${basedir}/src/fonts/frutiger.ttf</embedFile>
  <metricsFile>${basedir}/target/fonts/frutiger-metrics.xml</metricsFile>
</font>

In the SVG I used the same fonts and font names. A wierd thing s that it works fine when I used Batik in form of Squiggle, which is a Swing SVG viewer, written with Batik.

With XEP the result was worse. It lost gradients and some other artifacts from the SVG. No on the other hand, it actually found the fonts. So again XEP and Apache FOP had different problems. I don’t think XEP is using Batik to render the SVG into PDF.

Current state of “Documentation Nirvana”

• Tool chain is working good. Maven was a big win. Self contained project , easy to check out from Mercurial and just run.
• Raster images looks wierd in all my tests. This is almost a show stopper. Screenshots are necessary in my documents.
• Vector images work better. If I stick to Helvetica I think it is good enough.

I would welcome comments!

Docbook and Apache FOP

I have taken up Docbook again. It was too much configuration and fixing when I tried it a few years ago. But now I found a Maven plugin that makes it really easy. Fonts go in one directory, custom XSL in another, images and docbook files in a third. Then all I have to do is

mvn clean generate-resources pre-site

to generate a shiny PDF in target. The plugin is called docbkx-maven-plugin.

This was actually close to documentation editing nirvana. But I have a really annoying issue. If I include raster files they get rendered in the wrong resolution. FOP is shoing them as larger and pixelized. I thought there might be something wrong with my settings or the plugin so I tried a commercial offering from OxygenXml.com. They also use Apache FOP as the default FO processor.

They replied to my support request (really good support, and it was only pre-sale questions):

It is a problem of the FOP processor which scales the images to a larger size ignoring the actual image size and the width and height set by the user. You should use a different FO engine like XEP for RenderX. […]

RenderX costs $360.

I have googled a lot and this seems to be a really old issue in Apache FOP. Anyone knows if there is a solution? Are they working on the issue?

SpringSource fixes policy

Good stuff!

Opening in the Spring conflict?

On the end of the TSS thread Rod Johnson seems to be willing to consider a compromise with the Spring community.

The suggestion put out by Greg Matthews was that SpringSource would provide tags on maintenance releases only for the most current major version of Spring. So when Spring 3.0 is released, users can use CVS tags to download 3.0.*, up until 3.1 is released.

“e.g. no more tags on the 2.0 branch, continued tags on 2.5 until 3.0 comes out, then no more tags on the 2.5 branch.”

Builds made from these tags could be uploaded to the Maven repos.

Bug fixes for older releases will have to be done manually by patching.

Rod Johnson:

“The idea of tagging the current branch until the next major release comes out is an interesting compromise, and we will consider it.

I would love to have a genuinely collaborative dialog with the community on fine-tuning a fair and balanced outcome, and I’m happy that the discussion now seems to be trending that way.”

I think this is reasonable. It is what I would expect by an Open Srouce project. Normally OSS projects are mostly interested in the newsest version and often not that interested in maintaining old stuff.

I could live with this. But I don’t have the same trust anymore. What will they do next?

To mend the broken confidence, I think SpringSource needs to reach out to the community. Perhaps they should establish a contract with the community, “Community Bill of Rights”.

New Spring policy: maintenance branch to the rescue?

I listened to Alef Arendsen in Stockholm today and he said that the problem for non-customers could be solved by using the maintenance branch.

If you checkout from the maintenance branch you can follow what issues have been fixed by cross referencing with the Jira issues. You will not get unfinished new features - only bug fixes for your release.

We won’t get the official, blessed release, after QA. We will have to trust SpringSource to keep the maintenance branch stable. And we will have to track issues so that our issues are fixed when we build.

On the other hand, the Territory Manager of SpringSource for Europe said that bug fixes might be committed in two batches. You have the risk of checking out in between.

I still have two worries:

* What is the quality of the maintenance branches? I haven’t looked at the Spring CVS for a long time. Will what Alef suggest work?

* Is this just the first step? As Alef said, SpringSource need more money, otherwise Spring will not exist anymore (!). What if this first tough message isn’t resulting in more customers and subscriptions?

What do you think?

Update: Looking at the Spring CVS, it doesn’t seem like they do a lot of maintenance branches? So how is this going to work?

The SpringSource FAQ makes it even worse

Now SpringSource have published an FAQ about the license change (yes, it is a license change). Spring will be dual licensed. The source tree will be using ASF and be considered Open Source. It will not have tags for maintenance releases. There is no way to get bug fixes three months after a release from the Open Source tree.

All maintenance releases will be distributed under a commercial license. You CANNOT distribute them to others, even if you pay for them.

This is really bad.

I was supposed to go to a Spring seminar in Stockholm today. I wonder why I should go. I will not be using Spring in new projects in the future.

Best summary of the problem with SpringSource new policy

I wrote about it here, but Alessandro Santini is explaining it better here.

It’s not about SpringSource making money - I hope they all get stinking rich. It’s not demanding that all software should be free. But it is about blurring the line between closed source and Open Source. And I could do without that.

Open Source culture means making it easy for the community to take part. SpringSource is in fact making the source tree useless for any real work.

Dark clouds over Spring

Rod Johnson writes:

Source code will be published in the source repository. After 3 months SpringSource will continue make maintenance releases as needed to support our customers. There will be no tags in the repository corresponding to those releases.

Rod says in a clarification that the new policy “only affects those who are unwilling to go near source code”. But that is wrong.

The big change is that there will be no more bugfix releases available in binary form after three months AND there will be no tags in CVS. So there is no way to get bugfixes in a secure and maintainable fashion, unless you pay for it.

Here is a scenario from Daniel Fernández:

1. Spring 2.0 is released in Oct 3rd, 2006.

2. I find a bug in 2.0.2 (Jan 8th, 2007) which is important for me, and I report it.

3. Someone at SpringSource (or outside, it doesn’t matter) fixes it for 2.0.3 (Mar 9th, 2007).

4. As 2.0.3 was released more than 3 months after 2.0, I cannot have binaries for it.

5. Of course, I can checkout the source repository trunk, compile, and build but… I don’t have a tag, and I don’t have SpringSource’s “assessment” to know whether all parts will fit together, so I should consider this trunk unstable. This means, of course, that it will not go into my production systems. No bug fix for me.

6. Spring 2.5 is released on Nov 19th, 2007. More than 10 months after the last, buggy version I had the right to have (2.0.2).

You might be able to diff around in the CVS tree, but it will take ages to get to the fixes you need. And there will be no QA, other than the one you do for yourself.

A big change. I’m going to a Spring seminar on Wednesday. I hope there will be time to discuss this.

Groovy on NetBeans again

I tried installing Groovy support in Netbeans 6.1 on Windows and failed. I tried again on my Mac today but got this:

Should I stop trying? There where a lot of blog posts about Groovy support in NetBeans 6.1 before it was released, but is it really a supported feature?