Terminal plug-in for Eclipse

6. August, 2012

If you’re like me, then you’re spending a lot of time using console windows because some tasks are just so much more efficient (recalling old commands, pipes, …). If you use Eclipse, you will always struggle to squeeze the terminal window on the screen somewhere.

To help with this situation, Google has developed a plug-in to embed a command-line terminal into your workspace: ELT

It currently supports Linux (x86 32 and 64 bit) and Mac OS X (PPC, x86 32 and 64 bit) only. ANSI escape sequences (incl. color codes) are supported as well a hyperlinks.


CBI or Taking The Pain out of Eclipse Builds

20. July, 2012

When a project is young and dashing, mistakes are made. The PDE build process is such a mistake. If you ever tried to build Eclipse (or at least some of the older parts), then you know that this is brittle and the error messages are more like mysterious ramblings of an angry deity than helpful.

Enter stage CBI. From the FAQ:

 The CBI build of the Eclipse platform is intended to produce the same output as the PDE build, and thus facilitate packaging without noticeable change. The noticeable difference the CBI build of the platform makes is ease of use to build the platform. For example, the prototype has consistently demonstrated that a newcomer without prior experience can build the Eclipse platform with under 30 minutes of effort on a machine with a supported JDK & Maven.

What can I say?

Finally!


Jazoon 2012: Improving system development using traceability

4. July, 2012

When you develop a software, you will ask yourself these questions (quoted from here):

  • Is it still possible to accept a late change request? What would be the impact?
  • What is the overall level of completion of the system or a component?
  • Which components are ready for testing?
  • A failure occurs because the system is erroneous. What parts of the system should I check?

In his talk “Improving system development using traceability“, Ömer Gürsoy shows an approach to answer these. The idea is to trace changes end-to-end: From the idea over requirements to design, implementation, tests, bug reports and the product manual. For this to work, you’ll need to

  • Analyze
  • Document
  • Validate
  • Manage

At itemis, they developed tooling support. A plug-in for Eclipse can track changes in all kinds of sources (text documents, UML diagrams, requirement DSLs) and “keep them together”. It can answer questions like “who uses this piece of code?”

The answer will tell you where you need to look to estimate the impact of a change. That helps to avoid traps like underestimation or missing surveillance.

Today, the plug-in shows some promise but there are rough edges left. The main problem is integration with other tools. The plug-in supports extension points to add any kind of data source but that only helps if the data source is willing to share. The second problem is that it doesn’t support versioning right now. It’s on the feature list.

On the positive side, it can create dependencies from a piece of text (say a paragraph in a text file). If you edit other parts of the text file, the tool will make sure the dependency still points to the right part of the text. So you can make notes during a meeting. Afterwards, you can click on the paragraphs and link them to (new) requirements or parts of the code (like modules) that will be affected. Over time, a graph of dependencies will be created that helps you to keep track of everything that is related to some change and how it is related: Where did the request come from? Which code was changed?

Always keep in mind that tracking everything isn’t possible – it would simply too expensive today. But you can track your most important or most dangerous changes. That would give you the most bang for the buck. To do that, you must know what you must track and why.

A feature that I’d like to see is automatic discovery. Especially Java source code should be easy to analyze for dependencies.


e4 is here

28. June, 2012

Unless you live under a rock or you’re not using Eclipse, you can’t possibly have missed it: Eclipse Juno (or 4.2)

If you’re unsure what happened to 3.8 or 4.0 and 4.1, here is the story in a nutshell: A small team of Eclipse developers was concerned about the state of the platform (platform is the part of Eclipse that knows what a plug-in is, how to find, install and load them and arrange them in a neat way called “perspective”). When the platform was developed 2004, it was based on VisualAge. Don’t ask. Like all “visual” tools, it had … issues. Many of them were hardcoded into the platform. For example, there are many singletons in there. Many. Testing the platform is either a nightmare or slow or both.

The e4 team decided that something needed to be done. Only, it was risky. And it would take a long time. Which meant that the PMCs probably wouldn’t approve.

Therefore, they came up with a cunning plan: Develop a new platform (e4) alongside the official Eclipse releases. e4 would get a “compatibility layer” that would allow to run the old junk (like the JDT) but it would also allow to write plug-ins in a new, clean, understandable way. For example, in 3.x, you can use this code to get the current selection:

ISelection selection = getSite().getWorkbenchWindow().getSelectionService().getSelection();
Object item = ((IStructuredSelection)selection).getFirstElement();

The same code looks a bit different in e4:

@Inject
void setSelection(@Optional @Named(IServiceConstants.ACTIVE_SELECTION) Contact contact) {
    ...
}

e4 will call this method every time the user selects an instance of Contact in the UI.

The whitepaper gives some more details. Lars Vogel wrote a pretty long Eclipse 4 RCP tutorial.

After two years, e4 was deemed stable enough to make it the default release.

Conclusion: e4 doesn’t get rid of all the problems (p2, OSGi and SWT are still there) but it’s a huge step forward.

Related links:


If You Want Them to RTFM, Make a Better FM

16. May, 2012

If you’re interested in the conflicts between software and documentation, Alex Lagarde wrote a great post about that: Intent Discovery – Part 1 : the intents behind softwares.

It explains what the different (and conflicting) goals are between the “technical space” (source code), “model space” (design and architecture) and “document space” (what people need to use the software successfully). And he promises some solutions with the new Eclipse project “Intent” (and the second post in the series).


Eclipse Suddenly Takes Long to Start Unit Tests

10. May, 2012

When starting a JUnit test in Eclipse suddenly takes ages (the process starts quickly as you can see in the Console view but it takes ages until the tree of tests appears in the JUnit view), you might experience troubles with IPv6.

The background of the issue: Modern OSs assign your network cards two addresses, one for the old IPv4 and one for the new IPv6. When IPv6 isn’t configured correctly, Eclipse will try to connect via this route and it will take some 30 seconds for Eclipse and the JUnitRunner process to begin talking to each other.

The quick fix is to disable IPv6 or to tell Java to prefer IPv4:


Why OSGi Qualifiers Aren’t Working

13. April, 2012

If you don’t understand how OSGi bundles get versions: You’re not alone.

On paper, the rules are pretty simple and straightforward.

In reality, the rules are broken by many Eclipse bundles because the tools don’t help to enforce them (Alex Blewitt wrote two great posts about that: “Why OSGi qualifiers aren’t working” and “Using Humans to solve a Tooling problem“). It’s not a rare problem either. Alex found 10% of the bundles got a new qualifier but didn’t actually change. That doesn’t take bundles into account which did change but the version wasn’t bumped.

When I started on an automated converter to turn Eclipse bundles to Maven artifacts, I hit the same problems. Some bundles get rebuild for no apparent reason, some have changes but the version wasn’t bumped.

This causes some problems. First of all: Which of those two qualifiers is “bigger”? “v20120119-1537″ or “xx-20120301-1000-e37-RELEASE”?

And if you think that’s probably a mistake: That’s the qualifier for org.eclipse.jdt.core.source. It’s one of the core bundles for Eclipse. If even the JDT people don’t get it right, there isn’t much hope.

When  building something with Maven, you have something similar: SNAPSHOT versions. But unlike Eclipse,

  • Maven forces you to drop the SNAPSHOT when you build a release
  • Maven replaces the string “SNAPSHOT” in the version with a build timestamp. This gives a consistent version scheme.
  • There are tools that check for SNAPSHOT versions
  • Maven can’t mix SNAPSHOT and releases in a repository (so you’re less likely to accidentally pollute your build or, worse, the build of someone else).

Unfortunately, OSGi have abandoned -SNAPSHOT versions for R5.

But maybe we can fix the problem on the Eclipse side. If you care, support Bug 376718 – Strip qualifiers for release builds.


When Eclipse Won’t Start

13. April, 2012

There can be a couple of reasons why Eclipse refuses to start: Corrupted workspace, broken plugins or conflicting plugins. This blog post is about the last category.

How do you know that you’re affected? Start Eclipse with the command line option -debug. If there is a huge gap between “Time to load bundles” and “Starting application”, you’re on.

Start Eclipse in a debugger and set a breakpoint in org.eclipse.osgi.internal.module.ResolverImpl.findBestCombination(ResolverBundle[], ResolverConstraint[][], int[], List<ResolverConstraint>).

The interesting information is in the variable bestConflictBundles. This is basically a list of bundles that cause some kind of trouble. Usually, this is a bundle which has the singleton flag set but of which are two versions in the plugins folder (or in the plug-in list, if you started Eclipse from another instance of itself).

If you started Eclipse from itself (using a launch configuration), the solution is to open the “Debug Configurations…” editor, select the “Plug-ins” tab:

This tab has several interesting options: You can type (part of) a plug-in ID into the filter field to narrow down the huge list. If the list isn’t active, select “Launch with: plug-ins selected below only” above.

That way, if you want to disable all of BIRT, type “birt” and then click “Deselect all” to the right.

Next stop is the “Validate Plug-ins” button in the bottom left. This opens a dialog with all the problems the current selection has. This dialog isn’t modal! That means you can keep it open while you (de-)select plugins from the list. If your screen is big enough, you can move it so you can see the list and the “Validate” button. That way, you never need to close the dialog.

Otherwise, Alt+V is your friend.

In my example, the org.eclipse.jpt.jpa.db plug-ins cause trouble. As you can see, I pulled them out with a short text in the filter. Now, I can get rid of them with a single click on “Deselect all”. Validate … okay, things for worse.

But I don’t need anything from JPT for my tests, so I get rid of the whole lot. Validate … “No problems were detected.”

Sweet.


How I Came to Hate Orbit

29. February, 2012

Orbit is an Eclipse project which contains IP clean OSS code to be used in Eclipse projects.

Why is that important? Well, IP clean means that big companies who consume Eclipse code, can use it safely (their lawyers have to check the EPL once and after that, their developers can use any code they can find on eclipse.org).

Now, Eclipse writes a lot of source code but not everything. commons-io, for example, contains a lot of code which would be really cool to have for Eclipse projects.

Orbit was created to have just that: Copies of OSS code from all kinds of places relicensed under the EPL. Sweet.

Enter stage: maven.eclipse.org

The idea behind maven.eclipse.org is to provide projects outside of the Eclipse foundation a place where they can find Eclipse’s OSGi bundles as Maven artifacts (which are easier to consume when you build your projects with Maven). Sweet 2.

To make the Eclipse bundles available on maven.eclipse.org, I need to convert them. Part of that process is to assign each Eclipse bundle (which has bundle ID and a version) a Maven coordinate (which consists of group ID, artifact ID and version). That’s not always simple but I’ve found a rule that works pretty well.

If it wasn’t for Orbit.

Orbit contains bundles which you can also find on Maven central. One example is commons-io.

And Orbit didn’t simply copy the JAR from Maven Central – they changed it. In this case, the changes are purely for legal reasons (EPL license, moved a couple of files around). Not a big problem here. I could map the two to the same coordinate – except that you would sometimes build software which contains code licensed by Apache and sometimes code which is licensed by EPL. Worse, some other code might be under the viral GPL on Maven Central – linking that could turn your project into open source! Not a problem for most developers but it could be a problem for your legal department and guess which head is going to roll?

But there is more.

Let’s have a look at … org.apache.batik.pdf. This is a fragment of the Batik’s rasterizer JAR from Maven Central. In this case, we have several issues:

  • Orbit has split a single artifact from Maven Central into several Orbit bundles. Which bundle should get the same coordinate as the original Maven Artifact?
  • The Orbit bundle also contains code from commons-io and commons-logging. So it pollutes your classpath with classes that you don’t expect. Worse, someone (not the Eclipse guys) removed “unnecessary” methods from some classes copied from commons-io. So if the compiler sees this JAR on the classpath, you will get errors for many methods in the class IOUtils. Bad.
  • Some Orbit bundles have bugs fixed but the version hasn’t been changed – only the qualifier changed which works if you use OSGi to build your classpath but Maven doesn’t. A couple of bundles from org.apache.batik are among them (bug 329376).

While it might make sense from Orbit’s point of view to do this, it makes my life a bit complicated.


Maven Tool 4 Eclipse 0.10.0 Released

12. January, 2012

I’ve just release a new version of Maven Tools 4 Eclipse (Changelog). It fixes the two most pressing issues:

  • Bug 367461 – [mt4e] mt4e needs priming.zip
  • Bug 354381 – Error: groovy.lang.MissingPropertyException: No such property: args for class: m4e.ImportTool

Have Fun!


Follow

Get every new post delivered to your Inbox.

Join 334 other followers