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).
2 Comments | 
Software | Tagged: Documentation, Eclipse, Software, Software Development | 
Permalink
Posted by digulla
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:
Leave a Comment » | Software | Tagged: Eclipse, IPv6, Java, JUnit, Unit testing | Permalink
Posted by digulla
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,
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.
Leave a Comment » | Uncategorized | Tagged: Eclipse, OSGi | Permalink
Posted by digulla
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.
Leave a Comment » | Software | Tagged: Eclipse, Launch configuration, Startup | Permalink
Posted by digulla
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:
While it might make sense from Orbit’s point of view to do this, it makes my life a bit complicated.
Leave a Comment » | Software | Tagged: Apache Maven, Eclipse, Maven, mt4e, Orbit, OSGi | Permalink
Posted by digulla
I’ve just release a new version of Maven Tools 4 Eclipse (Changelog). It fixes the two most pressing issues:
Have Fun!
1 Comment | Software | Tagged: Apache Maven, Eclipse, Maven, Maven3, mt4e | Permalink
Posted by digulla
If you want to see BIRT built with Tycho, vote for this bug: [Build] Migrate build to Tycho
Leave a Comment » | Software | Tagged: BIRT, Build, Eclipse, Tycho | Permalink
Posted by digulla
A few days ago, kingargyle posted about “Push Button Builds.” The idea is that building a software should be as simple as triggering a light switch.
A good example are Maven (mvn install) or most automake builds (configure && make && make install). They usually just work and if they fail, they give you some context to work from.
A good negative example are Eclipse PDE builds: Often there is no build script. If there is a build script, it will fail with an obscure error message in an Ant script that was recursively called by about 100 other Ant scripts. Each Eclipse project uses PDE but each build has different prerequisites (which you must know). If the build uses p2 repositories, there is no way of telling whether two subsequent builds will produce the same result. Some projects try really hard to help newcomers to build their stuff with a recipe that needs 100+ easy steps. In four words: It’s a mess.
Or a surefire way to attract only the most dedicated committers because everyone else will be utterly demotivated very quickly (and you don’t want those, do you? 😉
So like Dave Carver, I would like to spread the idea. Make builds more simple. Here is an example and following Dave’s advice, I’m going to make the build script even more simple.
Why a script and not, say, a web site with instructions? Several reasons:
Leave a Comment » | Software | Tagged: Apache Maven, Build Management, Continuous integration, Eclipse | Permalink
Posted by digulla
When Eclipse is starting to act weird or completely refuses to start, the .metadata probably got corrupted. Now what? You could delete the .metadata directory and waste a couple of hours to restore the IDE to a useful state.
Here are some tips to speed up the process a lot:
Another useful plugin is the “save UI state” which saves the workspace layout and open editors after every change (based on the code here).
With a way to preserve your preferences, saving the project state the workspace layout, you should be able to quickly restore the IDE.
Related articles:
3 Comments | Software | Tagged: Eclipse, Workspace | Permalink
Posted by digulla
Note: This post is now obsolete since there is a newer release.
I just finished a new release of Maven Tools 4 Eclipse. It’s not written in Groovy and supports all the features of the old Python version plus a few new ones.
You can find instructions how to use it on the wiki page.
For now, you need to build the tool from source (which needs 1.4-SNAPSHOT from DecentXML) using Maven. I’m in discussion with the people at Eclipse to get a download link for the binary.
Update: The project page now has a download link.
9 Comments | Software | Tagged: Apache Maven, Eclipse, Maven, mt4e, Project Dash | Permalink
Posted by digulla
Dark Views 