RC1 of Testing Ready For Testing [Updated]

15. May, 2011

I’ve recreated the testing repository using the latest version of my Maven Tools 4 Eclipse.

To browse the repository, please use the Nexus interface.

If you pull in any dependencies from the repository, non-Eclipse artifacts will come from from Project Orbit. If you want non-Eclipse dependencies (like log4j) from Maven Central, you need to change your profiles.

Deactivate “m4e.orbit” and activate “m4e.maven-central“. From the command line, that’s “-P m4e.maven-central” but I suggest to put these into your settings.xml (add “<activeProfile>m4e.maven-central</activeProfile>” to it).

Note that you don’t need to deactivate the profile m4e.orbit. As soon as you specify a profile on the command line or via the settings, it’s deactivated automatically.

“mvn help:active-profiles” and “mvn dependency:tree” are your friends.

Let me know if you find anything missing, odd, broken by  filing a bug or posting a comment here.

UPDATE 2011-05-30

Some dependencies from the new repo can also be found on Maven Central. One nasty problem is that both repos contain org.eclipse.equinox.app but the version from Maven Central contains odd dependencies which break your build.

To fix this, add this to your parent/root POM:

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.eclipse.dash</groupId>
        <artifactId>dependency-management</artifactId>
        <version>3.6.2</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    <dependencies>
  <dependencyManagement>

This will limit all version ranges to the versions found in our new repository. Since Maven Central didn’t import new versions for at least one year, this should fix all problems.

Related posts:


Maven Tools for Eclipse: M2 Repository Analysis And Dependency Management

13. May, 2011

I’ve finished RC1 of my set of tools to import Eclipse plug-ins into Maven 2 repositories. You can find the source on github. It needs Python 2.7 and lxml. pip is your friend.

The new features: There is now a tool to analyze the M2 repository for oddities. Currently, it can find these issues:

  • Dependencies which are used but not part of the repository
  • Dependencies which are used with different versions or version ranges (i.e. when one POM includes a dependency with 1.0 and another POM pulls in the very same dependency with version 1.1)
  • Dependencies which are used without versions or version ranges or a catch-all version like [0,)
  • Several versions of the same artifact in the repository

Plus it prints a list of all POMs in the repo with files (jar, pom, sources, test-sources, …). Here is a sample report.

The last tool can create a POM file with a dependencyManagement element containing the versions of the POMs in the repository. You can use this to nail down all versions to the ones existing in your repository (so you don’t accidentally pull in something you don’t want).

Lastly, I’ve enhanced the patch tool. Instead of overwriting replaced dependencies, it will now move them into a new profile. This way, users of the repository can specify which dependency they want (the one from the repository or, say, one from Maven Central).

I will try to build a new testing repo over the weekend so we can start wrapping up the necessary patches for a release.

Related posts: Eclipse 3.6.2 Artifacts for Maven 2


Good comparison between JAXB and Simple XML

11. May, 2011

Here is a good comparison between JAXB and Simple – XML SerializationHow Does JAXB Compare to Simple?


Project Ceylon, Successor for Java?

14. April, 2011

A lot of languages compete for the king’s seat taken by Java. Most of them solve a lot of problem with Java but none of them really takes the win. As I say: “Why is there more than one database? Because they all suck.”

Now Ceylon enters the stage (slides from the presentation). The main goal is to clean up the SDK while keeping an eye on what was good and what was bad with Java.

I’ve had my share with programming languages. On a scale between 1 and 10 (best), Python gets 9 from me. Java gets 6. Scala gets 5.

So how does Ceylon fare? At first glance, I’d give it a 7.

Pros:

  • Compact syntax. No packages, no classes.
  • I like to idea of the recursive block scope which gets rid of the very limited public/private and the ill fated package public. My only concern is how you can declare friends to something at a nested scope (for example for tests).
  • Short syntax to avoid NPEs. The approach allows to catch null pointers when they are assigned instead of when they are used. This means: If you find a bug, you’ll actually know what to do about it.
  • No new keyword! I really never understood why they added that.
  • No checked exceptions. No one got them right, anyway.
  • Just one constructor per class. I never use them anyway, and the new named argument syntax solves many of the existing problems.
  • Method references

Cons:

  • = vs. :=. Come on. In 2011, I still need to tell the compiler something it already knows? Also, looking at my code, I’ll probably use := a lot. So that means extra effort for me. Bad. Not everyone’s brain is wired for immutables.
  • “if (exists foo)” to check for null values. If I already have to use a special syntax to mark something as “can be null”, why do I need to mention that again in a condition? What’s wrong with “if(name)”?

Things that leave me puzzled:

  • local vs shared. I understand that the compiler can’t infer types for shared references in a single pass but who cares? The compiler is a tool that has to make me more productive. If the compiler needs two or three passes to resolve dangling type reference, so what?
  • How is the module system working? How do you bundle types in a container to keep the namespace clean?

Maven Tools for Eclipse: Patching POMs

11. April, 2011

I’ve added a new feature to my Maven tools for Eclipse: Applying patches to POMs.

This is a first step towards solving issues like this one: Bug 342046 – Invalid third party dependencies in Mavenized BIRT plugins

I’m not 100% happy with the result, though. Currently, the patch overwrites the original code. I think it would be much better if it created a profile instead. This way, you could see the original code and it would be simple to switch between different solutions for a problem in a POM.

The two standard problems are:

  • Bad version (no version, version range or wrong version)
  • Dependency name

The latter is introduced by the fact that Eclipse projects need to pull dependencies via Project Orbit. Orbit often renames dependencies so there is a naming conflict if you pull your dependencies from Maven Central. So we need a way to say “I’m using Orbit” and “I want Maven Central”.


HTML Generator in Java – renderSnake

19. March, 2011

There is another HTML generator: renderSnake. Here is how it looks:

public class Logo implements Renderable {
    public void renderOn(HtmlCanvas html) throws IOException { //@formatter:off
        html
            .div(id("logo"))
                .div(id("logo_text"))



                    .h1()
                        .a(href("index.html"))
                            .write("render")
                            .style().write(".snake { color:yellow; }")._style()



                            .span(class_("snake")).write("S")._span()
                            .write("nake")
                        ._a()
                    ._h1()
                    .h2().write("lean and mean HTML page writing machine")._h2()._div()



                ._div();
    }
}

I’m not sure about the “_” versions but it sure looks better than JSP 🙂

Related articles: Simple HTML Output From Java Using renderSnake


Getting Rid of Checked Exceptions in Java

18. March, 2011

So, you’re tired of rethrowing checked Exceptions that you can’t handle? Did you wish a long time ago IOException and SQLException were in fact RuntimeExceptions (as they should be according to Sun’s own definition)? The pain was there but it got kind of dull over the years? Acceptance of the inevitable and all that. How about this:

    @SneakyThrows
    public void doSomething() { 
        throw new Exception();
    }

Did I hear a “WTF”? Say hello to project Lombok.

IBM developerWorks has a great article to get you started with your own custom AST transformations.


Building RCP Apps With OSGi

16. March, 2011

Dave Orme wrote a really interesting article about building blocks of a RCP application with OSGiThe OSGi Building Block Pattern: An Invitation

I agree with him: The RCP wizard should really create projects to build a p2 repo and to package the bundles and features into something that a user can download and install.

Right now one of the major stumbling blocks when starting with Eclipse projects is that they either don’t build at all or that I fail to bundle/package them into some “output.”

The typical situation is that I’ve managed to import the project into my workspace. Now I get a lot of compile errors because bundles are missing in my IDE. Problem: I see the names but I have no idea at all where to download them. (See bug 340014 – “Offer a quick fix to install missing dependencies from p2 repositories”)

After manually googling for bundle names, trying to find the p2 repo which might contain them (in former times, p2 repositories offered a way to quickly browse them with a web browser – that doesn’t work anymore, so it’s poking in the dark). After a couple of restarts, the compile errors are gone.

At long last, I can start to fix my problem.

But now what? How can I create the “thing” that I need? (where “thing” can be a RCP app, a p2 repo, a bundle, a feature). Eclipse doesn’t allow to save the final after-build-step anywhere. Users must remember the steps: Export…, select the correct tool out 500, fill out the 100+ options in the little dialogs that pop up, rinse, repeat.

Welcome bug 340018 – “Allow to save export actions in a “launch” config”


TNBT – Object Teams

15. March, 2011

Object Teams, or OT/J for short, is a solution for the old Java problem “there is no I in ‘team'”: Most Java code is written as if the whole world was openly hostile. It’s riddled with final, private static, singletons, thousands of lines of code which almost do what you need except for this one line .. that you can’t change without copying the other 999.

Groovy’s solution: AST transformation. A topic for another post.

OT’s solution: create a Java-like programming language which allows you to extend code that isn’t meant to. A great example: Extending Eclipse’s Java compiler.

The Eclipse Java compiler is one of the most complex pieces of code in Eclipse (“5 Mbytes of source spread over 323 classes in 13 packages“). Unlike other compilers, it can compile broken code. The same technology is used to create byte code and error markers in the editor.

Stephan Herrmann wanted to add support for @NonNull and @Nullable. Usually, you’d create a branch, keep that branch in sync with the main branch, etc. Tedious. For every change that someone makes in the main branch, you must update your development branch. Even if the change is completely unrelated. CVS has a very limited concept of “related”. DVCS like Git or Mercurial are better at merging but they also don’t understand enough of Java to give the word “related” a useful meaning. “Same file” is the best you can get.

So instead of the tedious way, he used OT/J to create an OT/Equinox plug-in which patches the JDT compiler byte code. Sounds dangerous? Well, OT/J does all the ugly work. You just say “when this method is called, do this, too.” Sounds a bit like AOP? Yes.

Unlike AOP, it communicates intent more clearly. The code wasn’t designed to be the most compact way to define a “point cut” and then leave it to the reader to understand what this is supposed to mean. It better communicates the intent.

I’m not completely happy with the syntax, though. I don’t have specific points, only a general wariness. Maybe a careful application of Xtext would help.

Related Articles:

  • The Next Best Thing – Series in my blog where I dream about the future of software development

Declaring Relations Between Model Instances

14. March, 2011

I’ve been playing with Xtext 1.0 the last three weeks. The editor support is most impressive. It’s one of those well balanced technologies that work “right” out of the box, offer lots of places where to hook in to tweak things.

The last few days, I’ve been chewing on a hard problem: Relations. I could to this:

class A {
}

class B {
    A parent 1:*;
}

Read: Instances of B have a field “parent” that references instances of A. There is a list in A with all instances of B where the field “parent” is that exact instance. In simple words, it’s a parent-child relation between A and B. For each B, there is always one A. Each A can have several B’s attached.

Or like this:

class A {
}

class B {
}

relation A children 1:* B parent;

The first solution avoids repetition but when looking at A, you will miss the fact that it has fields. It looks empty but the declaration in B adds a field. I don’t like it. While it might work in this case, how do you map N:M? Where do you declare a many-to-many relation? In A or in B? My guts say: Don’t do it.

The second solution is also flawed if less so. Here, both classes are empty. I have to look up the relations to see what else is going on. And I have to repeat information. I don’t like it.

Time to take a step back and sleep over it.

Fast forward over the weekend.

How about this:

class A {
}
parent of
class B {
}

One word: Intent. A construct in a programming language should clearly communicate intent. Which is one of the weak points in Java: It’s hard to express what you intend with Java. It’s not impossible but it takes years of experience to avoid the luring shortcuts.

So this new syntax clearly states what I want: A’s are parents of B’s. No repetition. No odd “1:*” which every reader has to decode. Which you can get wrong.

But what if A is parent of more classes? Simple:

class A { }
parent of {
    class B { } parent of class X { }
    class C { }
    ...
}

See? It nests. Let’s add tree-like structures to the mix:

tree class A { }
parent of {
    class B { } parent of class X { }
    class C { }
    ...
}

So A gets a parent-child relation with itself. One word says everything: Ownership. Cardinality. Field names.

My gut likes it. Listen to your guts. Especially when a simple solution tries to lure you into a shortcut.