Skip to content

Posts from the ‘Stuff that rocks’ Category

8
Jun

Following Eclipse Milestones

With the Galileo Release coming up, you might find yourself having a hard time updating to the latest milestones AND keeping your favorite plug-ins up-to-date.

Did you know that you can migrate your additional plug-ins from one Eclipse install to another one? This can be a huge time-saver, especially for people who like to live on the bleeding edge.

Here's how:

  1. Install a fresh copy of Eclipse. Let's assume you install Eclipse 3.5 RC4 Cocoa 64bit (you're feeling lucky)
  2. Let's further assume you've got an existing install of Eclipse 3.5 RC3 Cocoa 32bit with some additional plug-ins, like FindBugs, WindowBuilder Pro, etc.
  3. After installing, start your newly installed instance of Eclipse
  4. Select Help -> Install New Software...
  5. In the Install dialog, click the Add... button to add a new update site:
    Eclipse Install Dialog

  6. In the next dialog, click on Local... to add a local update site:
    Eclipse: Add Site

  7. using the file chooser, browse to <path_to_your_OLD_eclipse_instance>/eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/ and click Choose to select that directory.
  8. Click OK to add the update site:
    Eclipse: Add Local Update Site

  9. The Install dialog will now list all plug-ins installed in the old location (i.e. your old Eclipse instance), clearly highlighting the ones that are not already installed in the new instance:
    Eclipse: Install from existing Eclipse install

  10. Check all features that you want to transport to the new location and continue the installation by clicking Next>.
  11. After confirming the license terms and clicking Finish, Eclipse will install the selected features from the old location into the new location. After the obligatory workbench restart you're good to go.

The only thing that I am wondering about is: why is there no first-class UI action (e.g. an import wizard) to do this?

Fork me on GitHub
25
May

Mac in Black: Taking Screenshots with Skitch

Last week, Heiko, Jan and I were talking about blogging about the tools that make our lifes easier on the Mac. "Isn't the Mac supposed to be making your life easier anyway?" you might ask. Well, most things really are easy with a Mac. However, there are some things that cannot be done easily with a Mac. More often than not, this is due to the fact that Apple tries to hide the complexity of computers from nosy users. Which is fine for beginners - but makes life harder for the pros. Thankfully, there is a vast array of tools out there that fill the gap and make life on a Mac easier.

I am going to try to post one tool recommendation per week - unless I am on vacation or speaking at a conference.

So without further ado, here is the first tool: Skitch!

Skitch is a tool that helps you to create screenshots. I need to create lots of screenshots: for documentation, to explain things to people by mail, and to annotate my bug reports. Of course, Mac OSX has several shortcuts to create screenshots, so what's the deal about Skitch?

First of all, Skitch allows you to view and edit your screenshot: press CMD+SHIFT+5, select the capture area and voilà - Skitch opens a window showing the screenshot just taken:

Skitch itself

You can now use the tools at the left hand side of the Skitch window to highlight certain areas of the screenshot, which comes on handy if you're filing a bug report for your favorite open source tool.

When you're done with editing, you can either drag the image to another application (using the "drag me" tab at the bottom of the window) or you can post the image to the web. I have set up Skitch to use my Flickr account, so I can use the images in other tools right away (I am writing my blog posts in Mars Edit, which has a great Flickr integration, so I've got a complete tool chain here). Skitch supports a number of file formats (JPG, SVG, PDF, TIF, GIF, BMP and native Skitch), so you can select the desired file format before sending the image to the web or dragging it to another application.

All images are also stored in a local history, so if you need to go back to one of the screenshots you took a while ago, no problem with Skitch.

Skitch really has made my life on my Mac easier because it integrates with other tools (both online and offline) so well and because it eliminates many steps that made dealign with screenshots so cumbersome before.

You can download Skitch beta from http://www.skitch.com. You will be asked to sign up, however, both the download and the software will work without registering.

Happy screen shooting :-)

5
May

Advanced WikiText

In my recent posting, I showed you how to use Mylyn WikiText to easily create documentation for your project.

In this installment, we're going to look at four things:

  1. How to create PDFs
  2. How to automate your publishing process
  3. How to split your documents to facilitate team work
  4. How to use DocBook as an intermediary format to add even more flexibility to your publishing process

Lots of stuff, so let's get started!

How to create PDFs

The WikiText documentation states you can create DocBook, HTML and Eclipse Help from Wiki markup. So, how to create PDFs? Well, there are many ways to create PDFs. If you just want to create PDFs inside the IDE, you can download the Textile-J PDF add-on for WikiText. Textile-J is the predecessor of WikiText. The reason why the PDF output is not included in WikiText is that some of the required frameworks need to transform to PDF are not yet IP-approved (see bug 258349 for more information).

To install the Textile-J PDF add-on, proceed as follows:

  1. Make sure you have WikiText 1.1.0 or better installed
  2. Add the Textile-J update site to your Update Manager: https://textile-j.dev.java.net/builds/wikitext/site
  3. Refresh the Update Manager. You should now see Textile-J WikiText PDF in the list of available features.
  4. Select Textile-J WikiText PDF and click Install
  5. Restart Eclipse as requested

You can now right-click on any wiki file (*.textile, *.mediawiki, *.confluence, *.twiki, *.tracwiki and select Textile-J -> Generate PDF from the context menu.

How to automate the process

If you want to create PDFs outside the IDE (e.g. on your CI server using ANT), you need to create a build file:

<project name="how-to-use-wikitext" default="wikitext2pdf" basedir=".">
<property name="wikitext.standalone" value="lib"/><!-- path to wikitext standalone package -->
<path id="wikitext.classpath">
<fileset dir="${wikitext.standalone}">
<include name="org.eclipse.mylyn.wikitext.*core*.jar"/>
<include name="net.java.dev.textilej.wikitext.*core*.jar"/>
<include name="net.java.dev.textilej.wikitext.*lib*.jar"/>
</fileset>
</path>
<taskdef classpathref="wikitext.classpath"
        resource="org/eclipse/mylyn/wikitext/core/util/anttask/tasks.properties" />
<taskdef classpathref="wikitext.classpath"
        resource="net/java/dev/textilej/wikitext/pdf/core/util/anttask/tasks.properties" />
<target name="wikitext2pdf" description="Generate PDF from textile">
<wikitext-to-pdf markupLanguage="Textile">
<fileset dir="${basedir}">
<include name="documentation.textile"/>
</fileset>
</wikitext-to-pdf>
</target>
</project>

By the way, there are ANT tasks for all other output formats as well, so you can automate the creation of Eclipse Help, HTML and DocBook, too:

<wikitext-to-docbook markupLanguage="Textile">
<fileset dir="${basedir}">
<include name="documentation.textile"/>
</fileset>
</wikitext-to-docbook>

How to split your documents to facilitate team work

Now that you know how to transform Wiki markup to various output formats, you might wonder how to split your Wiki files into smaller chunks so the members of your team can work on them separately. This is something which is very easy with, say, LaTeX or DocBook because they both have the concept of importing other documents. In Wikis, there usually is no such thing as importing another Wiki page - you rather link to that other page. If you're writing a documentation, this isn't sufficient, however. You really need to be able to import document fragments.

Instead of adding the notion of imports to WikiText, I decided to control the assembling of the master document by using a little bit of ANT wizardry and a text file.

The text file (named index.txt controls the order in which the document fragments ned to be glued together:

introduction.textile
grammar_language.textile
newnoteworthy.textile

The build.xml now needs to be enhanced so that it reads the control file and use this information to assemble the Wiki files in the order requested:

<target name="assemble">
<loadfile srcfile="doc/index.txt" property="inputfiles">
<filterchain>
<tokenfilter>
<replacestring from="\n" to=","/>
</tokenfilter>
</filterchain>
</loadfile>
<concat destfile="documentation.textile" append="false" fixlastline="yes">
<filelist dir="doc" files="${inputfiles}"/>
</concat>
</target>

So what happens here is that we read in the contents of the index.txt file, concatenate all file names, separated with a comma to one large line and feed that large line into the concatenate task that will then concatenate the contents of all those files in the given order so we get one big file.

After that, the big file can now be processed as usual:

<target name="generate-pdf" depends="assemble" description="Generate PDF from textile">
<wikitext-to-pdf markupLanguage="Textile">
<fileset dir="${basedir}">
<include name="documentation.textile"/>
</fileset>
</wikitext-to-pdf>
</target>

How to use DocBook to gain more flexibility

DocBook has been around for quite some years now and together with LaTeX still will give you the most flexibility when it comes to documentation engineering. I have been using both LaTeX and DocBook to write all sorts of documentation, ranging from my diploma thesis to open source project documentation and have found both the be versatile and reliable, but also quite verbose. Regarding flexibility, both give you the possibility to choose a document template / style of your liking. If none of the existing document styles match your needs, you can more or less easily create you own.

As WikiText supports creating DocBook from your Wiki files, we'll have a look at how to use this DocBook output to further process it. Here is what we need to do:

  1. Enhance our build script so it downloads the relevant DocBook files (libraries, basic styles and XSL transformations)
  2. Add targets to our build script that allow you to choose the output to be created: PDF, HTML or Eclipse Help

The whole process will look like this:

WikiTextDocBook ToolChain

Let's have a look at some crucial parts of the script.

We already saw how to assemble multiple Wiki files into one big Wiki file. The next step is to convert this file to DocBook:

<target name="wikitext2docbook" depends="assemble" description="Generate DocBook from textile">
<wikitext-to-docbook markupLanguage="Textile">
<fileset dir="${basedir}">
<include name="documentation.textile"/>
</fileset>
</wikitext-to-docbook>
</target>

After that, we need to convert the DocBook file to PDF:

<target name="docbook2pdf">
<echo>Converting article to PDF...</echo>
<delete file="${dest.dir}${file.separator}${documenat.name}.pdf"/>
<delete file="${dest.dir}${file.separator}${documenat.name}.fo"/>
<xslt in="${documenat.name}.xml"
        extension="xml"
        out="${dest.dir}${file.separator}${documenat.name}.fo"
        style="${document.stylesheet}">
<factory name="org.apache.xalan.processor.TransformerFactoryImpl">
<attribute name="http://xml.apache.org/xalan/features/optimize" value="true"/>
</factory>
<xmlcatalog>
<entity
                publicId="docbook.xsl"
                location="${docbook.dir}${file.separator}fo${file.separator}docbook.xsl"/>
</xmlcatalog>
<param name="generate.toc" expression="book toc" />
<param name="show.comments" expression="0" />
<param name="header.rule" expression="1" />
<param name="admon.graphics.extension" expression=".gif"/>
<param name="admon.textlabel" expression="0"/>
<param name="admon.graphics" expression="1"/>
</xslt>
<docbook2pdf
        source="${dest.dir}${file.separator}${documenat.name}.fo"
        target="${dest.dir}${file.separator}${documenat.name}.pdf"/>
<delete file="${dest.dir}${file.separator}${documenat.name}.fo" />
</target>

You can now control the output by supplying different stylesheets. DocBook XSLT comes with a variety of stylesheets for articles, books and online help systems. You can now easily create printed documentation AND online help from one source. DocBook XSLT supports EclipseHelp, JavaHelp, HTMLHelp (the Windows Help System) and even man pages!

So, next time you need to write documentation for a project you're working on, don't let it get you down. Instead, set up a trusty WikiText / DocBook toolchain and write down that documentation in Wiki markup in no time!

The whole build script and the sample document are available for download for free. If you need help setting up a tool chain or want to book me for consulting, drop me a line (peter dot friese at itemis dot com).

Many thanks to David Green and Steffen Pingel of WikiText and Mylyn who tirelessly fixed bugs I found, applied patches and created EA builds!

23
Apr

Getting started with WikiText

Documentation is the bane of all developers. Nobody likes to write documentation, but most people know we need it. Even more so in Open Source projects. If you don't have a decent documentation, it will be hard to find contributors which will eventually stall the projects ability to acquire new committers.

While documenting code is discussed quite controversial (see here, here, here and here), most people seem at least to agree that a high level documentation outlining the concepts of the software in question is appropriate.

The options to write high-level documentation are:

  1. Word processors like Word, OpenOffice, Pages and the like
  2. LaTeX
  3. DocBook
  4. Wikis

Using word processors for writing high-level documentation has serious drawbacks, especially when a whole team needs to contribute to the documentation. Do you remember master documents?

LaTeX is a great alternative, as it allows us to split documentation across several text files - this allows for efficient team work. Moreover, text files just cannot break and can be versioned / merged / diffed quite easily. However, LaTeX syntax is not for the faint of heart.

DocBook is great, too: it uses XML to describe documents and has a great number of transformations to about every output format you could think of (PDF, HTML, EclipseHelp, HTML Help, JavaHelp and even man pages! However, not everybody likes XML and in fact DocBook tends to be a little noisy.

So this leaves us with Wikis. They are great in many regards: you can write your documentation online, most wikis support versioning and diffing to a certain degree and most wikis have a decent collision detection that helps to work on documentation collaboratively. Thanks to offline Wiki editors for IDEs, we can even store wiki documents in local files.

Enter WikiText

WikiText is such a tool. It actually is very flexible, as it allows you to use a multitude of wiki dialects to write your documentation. It also supports a number of output formats (HTML, Eclipse Help, DITA, DocBook and FOP). What's more, it features a really nice text editor that can display Wiki markup almost in a WYSIWYG fashion. WikiText is developed and maintained by David Green.

So, without further ado, here is a quick introduction on how to install WikiText, writing your first document and transforming it to HTML.

Installing

Make sure you have a recent version of Eclipse installed. Then:

  1. Point your update manager (Help -> Install new software) to the Mylyn Update Site (http://download.eclipse.org/tools/mylyn/update/weekly/e3.4)
  2. Select the most recent version of Mylyn WikiText (as of this writing, this is WikiText 1.1.0.I20090423-1700-e3x) and install

After the obligatory Eclipse restart, you can start using the WikiText editor.

Writing your first document

  1. Create a new project (File -> Project... -> General -> Project
  2. Create a new file. We will be using the Textile wiki syntax, so let's name it HelloWorld.textile
  3. Enter some text:
    h1(#id). An HTML first-level heading
    
    Textile syntax is really simple. You can _emphasize_ text or *emphasize it even more*.
    
    Scaled images:
    !{width: 50%}images/eiffelturm.jpg!
    
    Enumerations also are very easy:
    
    * An item in a bulleted (unordered) list
    * Another item in a bulleted list
    ** Second Level
    ** Second Level Items
    *** Third level
    
    # An item in an enumerated (ordered) list
    # Another item in an enumerated list
    ## Another level in an enumerated list 
    
    Let's have more headings:
    
    h2. An HTML second-level heading
    
    Here is a table:
    
    |_. Header |_. Header |_. Header |
    | Cell 1 | Cell 2 | Cell 3 |
    | Cell 1 | Cell 2 | Cell 3 |
    
    h2. An HTML third-level heading
    
    Here is some code:
    
    bc..
    package org.eclipse.workflow;
    
    public class Workflow {
    
    }
    
    p. Here is a plain old paragraph. It needs to start with "p." to mark the end of the code block above.
    
    h4. An HTML fourth-level heading
    
    Of course, we can also have hyperlinks: "Peter's homepage":http://www.peterfriese.de 
    
    h5. An HTML fifth-level heading
    
    h6. An HTML sixth-level heading
    		
  4. Create a new subfolder images and place an image in his folder. I used this one.

You can always switch over to the preview pane, but you will notice that the source editor already does a decent job at rendering the text in a kind of WYSIWYG manner:

WikiText markup and preview

Transforming your document to HTML

In order to convert your document to a nicely rendered HTML document, just right-click on HelloWorld.textile in the package explorer and select WikiText -> Generate HTML. This will create anew file HelloWorld.html in the same directory. Double-click it to open it with a browser:

HelloWorld.html

Automating, PDF, splitting documents,...

I hope I could whet your appetite. In the next installment, I am going to show you how to automate the process of transforming WikiText documents into output documents, how to create PDF (by way of exploiting DocBook) and how to split your documents into smaller chunks so you can work on them as a team. Stay tuned!

2
Apr

How Twitter solved my P2 problems during my lunch break

Today, I wanted to migrate from Eclipse 3.5M5 to Eclipse 3.6M6 (I know, it's a bit late for that already - but then, I had been busy with #eclipsecon and preparing the Stupid Modeling Talk during the past weeks).

As of course I've got quite a number of additional bundles installed (e.g., EMF, Window Builder, Mylyn, Xpand and Xtend), I wanted to re-use them. I recalled that a while back someone (probably Chris?) blogged that it basically is possible to use an existing Eclipse installation as a local update site. However, I couldn't find the blog posting describing how to do that.

Given the fact it was about lunch time, I decided to let the #wisecrowd figure out how to solve my problem. So I twittered "desperately looking for a hint how to use an existing Eclipse install as a P2 repo. Goal:transport features from my M5 install to a fresh M6".

So, during my lunch break, the wise crowd (Kai, Ekke, Boris and Paul) sent me their opinions on the matter:

How Twitter solved my P2 problem during my lunch break

At first, it seemed like there is no solution, but in the end Paul's tweet reveals the solution I was looking for:

Add eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/ as a local update site.

All of you out there who still doubt the practical use of Twitter: you really should give it another try.

23
Feb

The iPhone has an innovative user interface. The iPhone has an innovative user interface?!

My colleague Wolfgang Frank recently blogged about innovation at Apple. His post contained a link to a video of James Gosling demonstrating the Star7 PDA:

The concepts of the GUI seem to be quite familiar to those who know the iPhone, don't they? Have a look at this:

"This is the day I've been looking for for two and half years"

If you come to think of it, the Star7 PDA prototype development took place in the early 90's. Steve Jobs' introduced the iPhone in his keynote speech in 2007. "Two and a half years..." Did they really invent the iPhone from scratch? If so, Apple seiously suffers from the Not Invented Here Syndrome...

There is an interesting discussion regarding whether Apple invented all those concepts on their own. One commenter writes:

Do anybody think Sun is able to come up with anything like iPhone? I don't think so look at the Swing UI. after many years and many new L&F wots the difference? There is not a UI that can rival the default UI of the OS X nor Windows. Face it.....Sun is not know for designing.

Oh, and we must not forget Google Android:

Funny how all those things resemble each other so much...The bottom line is that among the three devices, the Star7 is the only really innovative one. It had been way ahead of it's time. What a pity Sun didn't make more of it.

2
Jul

Reporting bugs has never been easier…

Reporting bugs for Eclipse or one of it's various subprojects has never been easier than with Eclipse Europa. If you haven't grabbed your copy of Europa yet, you should do so now. While waiting for the download to complete, read on to find out how to report your bugs.

Traditionally, in order to report a bug against an Eclipse-related project (or component), you had to switch over to your browser, jump to https://bugs.eclipse.org/bugs/ and step through a rather tedious wizard that tried to help you find out whether you're about to report a real bug (or spam the Eclipse bugzilla with duplicates) and the appropriate product and component.

No longer! In the brave new world of Eclipse Europa, just select Report Bug or Enhancement from the Help menu (inside Eclipse).  In the dialog showing up, select Eclipse.org as your task repository and voilá! you are presented with a list of all available products. After selecting the desired product, you can enter all bug details in the bug editor:

Bug editor

Best of all: after committing the bug to the Eclipse bugzilla by clicking the Create New button in the bug editor, a link to the new bug is created in your local task list for later reference.

Thanks to Mik Kersten and the Mylyn team for making this possible!

21
Jan

Generated or not, that is the question…

Finally, I ventured into the world of EMF. One of the biggest challenges with EMF is to tell which classes and methods have been generated by a code generator and which ones have been written by a human being. Of course, EMF supports the @generated marker to tell the generator which classes and methods have been generated (and may thus be re-generated and overwritten), but still it is difficult for a human reader to tell the generated parts from the non-generated by just having a quick look at the code.

Some time ago I blogged about Eclipse color decorators - a great way to visually express certain charcteristics of your code. Wouldn't it be great to use color decorators to highlight the non-generated parts of your EMF code? By just looking at the package explorer, you could see which are the methods you coded manually.

Enter emf.bits! This is a handy little plug-in that allows you to highlight generated and non-generated code using two different colors. Highlighting takes place in structured viewers (e.g. package explorer and outline): All elements that have been marked as @generated will be displayed in different color (blue by default, but you can adjust this using the preference dialog). The same goes for elements that have been marked as @generated NOT - these will be displayed in different color (red by default). I adjusted the preference so that all generated code is displayed in gray, whereas non-generated code is displayed in black. This way, generated code is less visible than non-generated code and I can focus on the non-generated code:

Click to see larger image.

21
Oct

Eclipse color decorators rock!

Want to see which resources are ignored in your workspace? Use Eclipse color decorators! Here's how:

  1. Window -> Preferences
  2. Team -> Label Decorations
  3. Check the Enable font and color decorations box
  4. Click the hyperlink Colors and Fonts
  5. Open the category CVS
  6. You can now change the color and font for outgoing changes and ignored resources

I set the ignored resources foreground color to light gray and the outgoing changes font to bold - now I can see what is going on regarding CVS activity. Great!

14
Aug

Podcasting with a Palm Device

Podcasting seems to get momentum. Today, I dropped by Frank Westphal's web site. Frank has a very nice podcast named "Tonabnehmer" dealing with Agile Software Development.

Since I do not own an iPod, but instead call a Palm Tungsten E my own, I wondered whether I could use my Palm for listening to podcasts. Yes, I can! Here's how I did it:

  1. First, get a podcast aggregator. I use Doppler.
  2. Get an MP3 player for your Palm. I use Real One Player for Palm, which came with my Tungsten E.
  3. Now it is about time to subscrie to a podcast feed. Here is the link to Frank's Tonabnehmer: http://frankwestphal.podhost.de/rss
  4. Doppler supports sending all downloaded files to an external programm, e.g. iTunes. That's where we can plug-in!
  5. Download this ZIP file and place the contained batch file in a directory of your choice.
  6. You'll have to adjust the path information in the file, of course.
  7. Open the Doppler config dialog and associate MP3 files with your new command file. The application field must contain the path to the batch file you just extracted, the parameters field must contain the text "{1}".
  8. Now, place an SD card in an SD writer attached to your computer and start downloading a podcast. After downloading has finished, the batch file will copy the MP3 files to your Palm's SD card.
  9. Just place the SD card back into your palm and you're ready to go!