The Object Teams Blog

Adding team spirit to your objects.

Posts Tagged ‘Indigo

Between the Times

with 4 comments

This week is (supposed to be) “quiet week” at Eclipse: Release Candidate 4 is in place and more testing is being done before the final Indigo Release. Time to speak of s.t. that the Object Teams project has neglected a bit in the past: compiling / building with Maven.

Edit (June 2014): In a good tradition of using quiet week I’ve updated the Maven support for OT/J 2.3.0 (Luna).

Compiling OT/J with Maven

In the days of Maven2, pluging-in a non-standard compiler required fiddling with the nexus compiler plugin, which was buggy and all that. With the recent development around Maven3 and Tycho things became easier. The following pom-snippet is all you need to tell Maven to use the OT/J compiler:

<build>
    <pluginManagement>
        <plugins>
            <plugin>
                <!-- Use compiler plugin with tycho as the adapter to the OT/J compiler. -->
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>1.6</source>
                    <target>1.6</target>
                    <compilerId>jdt</compilerId>
                </configuration>
                <dependencies>
                    <!-- This dependency provides the implementation of compiler "jdt": -->
                    <dependency>
                        <groupId>org.sonatype.tycho</groupId>
                        <artifactId>tycho-compiler-jdt</artifactId>
                        <version>${tycho.version}</version>
                        <exclusions>
                            <!-- Exclude the original JDT/Core to be replaced by the OT/J variant: -->
                            <exclusion>
                                <groupId>org.sonatype.tycho</groupId>
                                <artifactId>org.eclipse.jdt.core</artifactId>
                            </exclusion>
                        </exclusions>
                    </dependency>
                    <dependency>
                        <!-- plug the OT/J compiler into the tycho-compiler-jdt plug-in: -->
                        <groupId>org.eclipse</groupId>
                        <artifactId>objectteams-otj-compiler</artifactId>
                        <version>${otj.version}</version>
                    </dependency>
                </dependencies>
            </plugin>
        </plugins>
    </pluginManagement>
</build>
 
Edit (June 2014): As of version 2.3.0 (Luna) the groupId has been changed to org.eclipse.objectteams (meanwhile, 3-part group IDs are the de-facto standard for Eclipse projects).

This relies on the fact, that the OT/J compiler is compatible with the JDT compiler, good.

To make things go smooth in various build phases a few more bits are required:

  • provide the OT/J runtime jar and its dependency (bcel)
  • tell surefire about required command line arguments for running OT/J programs

These basics are collected in a parent pom so that all you need are these two snippets:

<repositories>
    <repository>
        <id>ObjectTeamsRepository</id>
        <id>ObjectTeamsRepository</id>
        <name>Object Teams Repository</name>
        <url>http://download.eclipse.org/objectteams/maven/3/repository</url>
    </repository>
</repositories>
<parent>
    <groupId>org.eclipse</groupId>
    <artifactId>objectteams-parent-pom</artifactId>
    <version>2.0.0</version>
</parent>
 
Edit (June 2014): Again: as of version 2.3.0 the groupId is org.eclipse.objectteams.

This converts any Java project into an OT/J project, simply enough, huh?

At least compiling and testing works out-of-the box. Let me know what additional sophistication you need and if adjustments to other build phases are needed.

OT/J over m2e

Well, I’m not much of a Maven expert, but I’m an Eclipse enthusiast, so, how can we use the above inside the IDE?

The bad news: the m2e plug-in has hardcoded its support for the compiler plugin to use “javac” as the compiler. Naive attempts to use tycho-compiler-jdt have failed with the infamous "Plugin execution not covered by lifecycle configuration".

The good news: By writing a tiny OT/Equinox plug-in I was able to remedy those issues. If you have the m2e plug-in installed (Indigo version), the normal “Update Project Configuration” action will suffice:
Update Project Configuration

After that, the project is recognized as an OT/J project, both by the IDE …

… and also by maven …
Running mvn test

Where to get it?

The mentioned plug-in is brand-new and as such it is not part of the regular OTDT distribution. OTOH, the plug-in is so simple, I don’t expect a lot of changes needed. So, if you have an Indigo-ish Eclipse just add this update site:

Then install “Maven Integration for Object Teams (Early Access)”:
Install the Maven Integration for Object Teams

Don’t forget the <repository> and <parent> definitions from above and you should be ready to go! Yesss, sometimes it pays off that OT/J is a kind of Java, a lot of the tooling can just piggy-back on what’s already there for Java 🙂

Advertisements

Written by Stephan Herrmann

June 14, 2011 at 14:56

Posted in Eclipse, Object Teams

Tagged with , , ,

A Short Train Ride

with 2 comments

Less than a week ago I happily announced that Object Teams is on the Indigo Train.
Much water has gone under the bridge since then and the above statement is history.

Events where triggered by what was actually a little bug in the b3 aggregator. Only by way of this bug some people noticed that there was a ”’patch feature”’ inside the repository, i.e., a feature (“Object Teams Patch for JDT/Core”) that replaces the jdt.core plugin with a variant.

One part of me is very happy this bug occurred because finally an issue got the attention I had tried to raise at various occasions before. The lesson is:

Installing stuff with p2 may do other things than just adding new functionality, it may change existing stuff.

(see this post, e.g.).

The other part of me got very worried because during that debate some harsh statements occurred that would effectively amount to excluding Object Teams from Eclipse.org. That’s a little more attention than I had intended. As in any heated debate some of the arguments sounded to me more like ideology than anything that could possibly be discussed open-mindedly.

I had mixed feelings regarding the technical scope: the outcry only banned one specific technology: patch features. I don’t see how the goal to protect a project’s bits and bytes against influence from other projects can be achieved without also discussing: access to internal, byte-code weaving and – worst of all, I believe – reflection. To be perfectly open: Object Teams uses all these techniques except for reflection. Personally, I would even argue for banning projects that do use setAccessible(true), but that’s not a realistic option because then quite likely the whole Train would dissolve into a mist.

I am actually guilty of a technical simplification during this debate: I focused too much on the idea that a user would explicitly select features to install, not accounting for the possibility that the jdt.core plugin can well be pulled in invisibly due to dependencies among plugins. So, yes, if Object Teams would still be in the repository, and if a user installed a package without the JDT and if that user did never select to install the JDT and if that user selects another feature that implicitly requires the jdt.core plugin, then that user would unexpectly install the OT variant of the jdt.core. I agree that this is not ideal. I personally would have been happy to take this risk because I know how thoroughly the OT variant is tested for compatibility. And for the remaining minuscule risk I would have been happy to promise same-day fixes. But risk assessment naturally depends on perspective and I understand that others come to different conclusions when weighing the issues.

From two days distance I can already laugh at one implication of the central argument, paraphrased as: the JDT/Core team must be protected against harmful actions from the OT team. When spelling this out in names, one of the sentences reads: “Stephan Herrmann must be protected against harmful actions by Stephan Herrmann”. I should really be careful, because I’ll never be able to escape him!

Where to go?

  • As we’re banned from the Train, I willed hurriedly book a plane ticket to Indigo. Make sure we come by a Graduation office on the way.
  • I do hope that bug 316702 get’s sufficient attention now. Seriously: if you are so detrimentally determined about patch features, then the UI must report it. And if it reports this, it might as well report other techniques that have similar effects!
  • I appreciate any offers for helping OT/J towards a solution that avoids replacing a plugin. As of today and after more than seven years of looking at this, I see no way how this can be done, but that doesn’t mean we shouldn’t try still harder.
Unfortunately, the debate consumed all the time and energy I had planned for preparing a presentation at the EclipseCON Audition. However, Lynn finally made my day by letting me know that my submission is the lucky #42. So I’m making progress towards my all-seasons Eclipse collection 🙂

Written by Stephan Herrmann

November 18, 2010 at 14:32

Posted in Eclipse, Object Teams, OTDT

Tagged with , , ,

Object Teams is on the Train to Indigo

with 2 comments

Object Teams made the next step for even better integration in Eclipse: starting with today’s Indigo Milestone 3 we’re aboard! No further fiddling with URLs of update sites, simply select the Indigo site…

… and directly install the OTDT from there.

For those who haven’t tried Object Teams before, here are steps 1, 2 & 3:

  1. Walk through the Quick Start
  2. Read the basic concepts in our OT/J Primer
  3. Play with more Examples or browse some Object Teams Patterns

Improvements

The main concern of this milestone release was catching up with the Indigo train, so the list of bugs fixed is shorter than usual. But, hey, by upgrading to Eclipse SDK 3.7M3, the OTDT supports also some new JDT coolness, like, e.g., improved static analysis (I happen to have a finger in this pie, too 🙂 ).

Compatiblity

With each new release it is good to test compatibility with older software. So I loaded my previous experiment (“project medal”) into the new milestone. Much as I expected: that little adaptation of the JDT still works as intended also in the new version, which wasn’t possible with the original implementation. This again shows: in-place patching can never give you, what OT/Equinox excels in: evolvable, modular adaptation.

Written by Stephan Herrmann

November 13, 2010 at 02:47

Posted in Eclipse, Object Teams, OTDT

Tagged with , ,