Planet Eclipse
Planet Eclipse
Planet Eclipse
Planet Eclipse is a window into the world, work and lives of Eclipse hackers and contributors.
Looking for an RSS Newsreader? Try RSSOwl, it is built on Eclipse!
Last updated: February 11, 2011 04:29 AM (UTC)
Maintained by the Planet Eclipse admins.
Powered by:
Your Blog
If you would like your blog added to the feed, please have a look at our guidelines and then open a request in the Eclipse Bugzilla with your feed specific information.
Eclipse Committers can create their own blog on the Eclipse Blogs site.
Subscriptions
Abel Muino
Achim Brede
Ahti Kitsik
Alex Blewitt
Alex Radeski
Alexander Nyssen
Ali Burak Kulakli
Andre Oosthuizen
Andrea Zoppello
Andreas Hoegger
Andrei Loskutov
Andrew Eisenberg
Andrew Niefer
Andrew Overholt
Andy Clement
Andy Maleh
Angelo Zerr
Ankur Sharma
Annamalai Chockalingam
Anne Haugommard
Anthony Hunter
Antoine Toulme
Artur Kronenberg
Aurelien Pupier
BJ Hargrave
BPMN Modeler
Baptiste Mesta
Ben Vitale
Benjamin Cabe
Benjamin Muskalla
Benno Baumgartner
Benoit Langlois
Bernd Kolb
Beyhan Veliev
BioClipse
Birt World
Blaise Doughan
Blinki
Bob Balfe
Bob Brodt
Boris Bokowski
Brian Fitzpatrick
Brian Fitzpatrick
Bryan Hunt
Buddhika Laknath
COSMOS
Carlos Sanchez
Carlos Valcarcel
Cedric Brun
Chetan Kumar Kotha
Chris Aniszczyk
Chris Gross
Chris Recoskie
Christian Damus
Christian Meier
Craig Setera
Daniel Ford
Darin Swanson
Dariusz Luksza
Dave Carver
Dave Orme
David Black
David Bosschaert
David Bosschaert
David Green
David Kyle
Deepak Azad
Del Myers
Denis Roy
Donald Ralph
Donald Smith
Doug Clarke
Doug Schaefer
Eclipse Announcements
Eclipse Committer Reps
Eclipse Enthusiasts Poznań
Eclipse Labs - Most Active Project
Eclipse MAT
Eclipse Riena
Eclipse4SL
EclipseCon
EclipseLink Team
EclipseLive
Ed Burnette
Ed Merks
Egon Willighagen
Eike Stepper
Ekkehard Gentz
Elias Volanakis
Elliott Baron
Emil Crumhorn
Emilien Perico
Epsilon GMT
Erdal Karaca
Eric Rizzo
Erkki Lindpere
Erwin Tenhumberg
Etienne Juliot
Eugene Kuleshov
Eugene Ostroukhov
Fabian Steeg
Felipe Heidrich
Flavio Donze
Florian Lautenbacher
Florian Waibel
Francis Upton
Francisco Gortazar-Bellas
Frank Gerhardt
Frank Turovich
Fred Grott
Freddy Allilaire
Frederic Madiot
Glyn Normington
Gorkem Ercan
Goulwen Le Fur
Greg Wilkins
Gunnar Wagenknecht
Gyrex
Hannes Mueller
Hasan Ceylan
Heiko Behrens
Heiko Seeberger
Hendrik Eeckhaut
Hendy Irawan
Henning Faber
Henrik Lindberg
Herman Lintvelt
Hiroki Kondo (kompiro)
Holger Staudacher
Holger Voormann
Human Centered Web (HCW)
Ian Bull
Ian Bull
Ian Skerrett
Ilya Shinkarenko
Imran Abdul Rahiman
Ismael Juma
Itemis (Kiel)
Ivan Motsch
Ivar Meikas
JDT-UI and Text Team
JFace Data Binding Team
JSDT
Jacek Pospychala
Jae Gangemi
James Blackburn
James Ervin
James Sutherland
Jan Bartel
Jan Kohnlein
Jason van Zyl
Jeff McAffer
Jeff, Paul Simon
Jens Götz
Jens von Pilgrim
Jens von Pilgrim
Jerome Benois
Jesper Møller
Jesse McConnell
Jiang Hu
Jin Mingjian
Jochen Krause
Joern Weigle
John Bito
John Dang
John Graham
Jonas Boner
Jonas Helming
Jonathan Musset
Jordi Böhme López
Julius Shaw
Kai Kreuzer
Kai Toedter
Kaloyan Raev
Karl Beecher
Karsten Thoms
Ken Gilmer
Ken Ryall
Kenn Hussey
Kent Beck
Ketan Padegaonkar
Kevin Barnes
Kevin McGuire
Kevin Vu
Kim Horne
Kim Moir
Kiril Mitov
Knut Wannheden
Konstantin Komissarchik
Lars Vogel
Laurent Goubet
Lawrence Mandel
Les Jones
Litrik De Roy
Lucas Bigeardel
Lukasz Milewski
Lynn Gayowski
Maarten Meijer
Madhu Samuel
Manuel Selva
Manuel Woelker
Marcel Bruch
Marcel Gorri
Marcelo Mayworm
Marcelo Paternostro
Mariot Chauvin
Mark Melvin
Mark Phippard
Mark Powell
Markus Knauer
Markus Knauer
Markus Kohler
Markus Kuppe
Markus Scheidgen
Markus Tiede
Markus Voelter
Martin Fluegge
Martin Lippert
Martin Oberhuber
Martin Taal
Marty Jones
Mateusz Matela
Matthias Kempka
Matthias Sohn
Matthias Zimmermann
Max Rydahl Andersen
Meinte Boersma
Michael Scharf
Michael Spector
Michael Valenta
Michaela Greiler
Michel Parisien
Mickael Istria
Mik Kersten
Mika'l Barbero
Mike Milinkovich
Mike Wilson
Miles Parker
Miles Sabin
Mitch Sonies
Moritz Post
Mukul Gandhi
Mustafa Isik
Naci Dai
Nathan Gervais
Neil Bartlett
Nick Boldt
Nicolas Richeton
Nirav Thaker
Nirmal Sasidharan
Nitin Dahyabhai
Oisín Hurley
Olivier Thomann
Open Healthcare Framework
OpenNTF
Pascal Rapicault
Patrick Paulin
Paul Bilnoski
Paul Trevithick
Paul Webster
Peter Friese
Peter Kriens
Peter Liu
Philipp Kursawe
Philippe Ombredanne
Philippe Ombredanne
Piotr Maj
Platform Debug Team
Polishin' Eclipse
Prakash G.R.
R uuml;diger Herrmann
RSE World
Radoslaw Urbas
Rafael Chaves
Raja Kannappan
Ralf Ebert
Ralf Sternberg
Ralph Müller
Releng
Remy Suen
Ricco Deutscher
Richard Gronback
Robert Konigsberg
Romain Bioteau
Ron Bermejo
Roy Ganor
SOA Tools Team
Sandro Boehme
Scott Kellicker
Scott Lewis
Scott Lewis
Scott Schram
Sebastian Benz
Sebastian Zarnekow
Sebastien Letelie
Serge Beauchamp
Seva Lapsha
Shaun Smith
Simon Chemouil
Simon Kaegi
Simon Zambrovski
SoC Blog
Stefan Daume
Stefan Dimov
Stefan Leopold
Stefane Fermigier
Steffen Pingel
Stephan Herrmann
Stephan Leicht
Stephane Begaudeau
Stephane Bouchet
Steve Northover
Steve Sfartz
Stéphane Drapeau
Suresh Krishna
Sven Efftinge
Swordfish Team
Tasktop Team
Terry Chen
Thibault Landre
Thomas Derflinger
Thomas Hallgren
Thomas Kratz
Thomas ten Cate
Tianchao Li
Tim Buschtöns
Tom Schindl
Tom Seidel
Tomasz Wesolowski
Tonny Madsen
Toomas Römer
Torkild Ulvøy Resheim
Tristan Faure
Ugo Sangiorgi
Vasanth Dharmaraj
Vincent Hemery
Vincent Zurczak
Vineet Sinha
Vineet Sinha
Virgil Dodson
Vojimir Golem
Wayne Beaton
Webtools News
William Candillon
William Piers
Wim Jongman
Xavier Maysonnave
Yves Yang
Zeb Ford-Reitz
Zoltan Ujhelyi
Welcome to Planet Eclipse
February 10, 2011
Donald Smith
Eclipse Hot New Product Showcase Filling Up!
We have some very cool organizations and products participating in the Hot New Products Showcase at EclipseCon, and space is limited. Please let us know if you have a hot new product you'd like to show off! - Don
by Donald Smith (noreply@blogger.com) at February 10, 2011 03:27 PM
Glyn Normington
Stumbling towards a better design
Some programs have a clear design and coding new features is quick and easy. Other programs are a patchwork quilt of barely comprehensible fragments, bug fixes, and glue. If you have to code new features for such programs, you're often better off rewriting them.However there is a middle ground that I suspect is pretty common in these days of clean code and automated test suites: you have a good program with a clear design, but as you start to implement a new feature, you realise it's a force fit and you're not sure why. What to do?I've recently being implementing a feature in Eclipse Virgo which raised this question and I hope sheds some light on how to proceed. Let's take a look.The New FeatureI've been changing the way the Virgo kernel isolates itself from applications. Previously, Equinox supported nested OSGi frameworks and it was easy to isolate the kernel from applications by putting the applications in a nested framework (a "user region") and sharing selected packages and services with the kernel. However, the nested framework support is being withdrawn in favour of an OSGi standard set of framework hooks. These hooks let you control, or at least limit, the visibility of bundles, packages, and services -- all in a single framework.So I set about re-basing Virgo on the framework hooks. The future looked good: eventually the hooks could be used to implement multiple user regions and even to rework the way application scoping is implemented in Virgo.An Initial ImplementationOne bundle in the Virgo kernel is responsible for region support, so I set about reworking it to use the framework hooks. After a couple of weeks the kernel and all its tests were running ok. However, the vision of using the hooks to implement multiple user regions and redo application scoping had receded into the distance given the rather basic way I had written the framework hooks. I had the option of ignoring this and calling "YAGNI!" (You Ain't Gonna Need It!). But I was certain that once I merged my branch into master, the necessary generalisation would drop down the list of priorities. Also, if I ever did prioritise the generalisation work, I would have forgotten much of what was then buzzing around my head.Stepping BackSo the first step was to come up with a suitable abstract model. I had some ideas when we were discussing nested frameworks in the OSGi Alliance a couple of years ago: to partition the framework into groups of bundles and then to connect these groups together with one-way connections which would allow certain packages and services to be visible from one group to another.Using Virgo terminology, I set about defining how I could partition the framework into regions and then connect the regions together using package, service, and bundle filters. At first it was tempting to avoid cycles in the graph, but it soon became clear that cycles are harmless and indeed necessary for modelling Virgo's existing kernel and user region, which need to be connected to each other with appropriate filters.A Clean AbstractionSoon I had a reasonably good idea of the kind of graph with filters that was necessary, so it was tempting to get coding and then refactor the thing into a reasonable shape. But I had very little idea of how the filtering of bundles and packages would interact. In the past I've found that refactoring from such a starting point can waste a lot of time, especially when tests have been written and need reworking. Code has inertia to being changed, so its often better to defer coding until I get a better understanding.To get a clean abstraction and a clear understanding, while avoiding "analysis paralysis", I wrote a formal specification of these connected regions. This is essentially a mathematical model of the state of the graph and the operations on it. This kind of model enables properties of the system to be discovered before it is implemented in code. My friend and colleague, Steve Powell, was keen to review the spec and suggest several simplifications and before long, we had a formal spec with some rather nice algebraic properties for filtering and combining regions.To give you a feel for how these properties look, take this example which says that "combining" two regions (used when describing the combined appearance of two regions) and then filtering is equivalent to filtering the two regions first and then combining the result:Being a visual thinker and to make the formal spec more useful to non-mathematicians, I also drew plenty of pictures along the way. Here's an example graph of regions:A New ImplementationI defined a RegionDigraph ("digraph" is short for "directed graph") interface, implemented it, and defined a suit of unit tests to give good code coverage. I then implemented a fresh collection of framework hooks in terms of the region digraph and then ripped out the old framework hooks and code supporting what in retrospect was a poorly formed notion of region membership and replaced this with the new framework hooks underpinned by the region digraph.I Really Did Need It (IRDNI?)It took a while to get all the kernel integration tests running again, mainly because the user region needs to be configured so that packages from the system bundle (which belongs in the kernel region) are imported along with some new services such as the region digraph service.As problems occurred, I could step back and think in terms of the underlying graph. By writing appropriate toString methods on Region and RegionDigraph implementation classes, the model became easier to visualise in the debugger. This gives me hope that if and when other issues arise, I will have a better chance of debugging them because I can understand the underlying model.A couple of significant issues turned up along the way, both related to the use of "side states" when Virgo deploys applications.The first is the need to temporarily add bundle descriptions to the user region. The second is the need to respect the region digraph when diagnosing resolver errors. This is relatively straightforward when deploying and diagnosing failures. It is less straightforward when dumping resolution failure states for offline analysis: the region digraph also needs to be dumped so it can also be used in the offline analysis.These issues would have been much harder to address in the initial framework hooks implementation. The first issue would have involved some fairly arbitrary code to record and remove bundle descriptions from the user region. The second would have been much trickier as there was a poorly defined and overly static notion of region membership which wouldn't have lent itself to including in a state dump without looking like a gross hack. But with the region digraph it was easy to create a temporary "coregion" to contain the temporary bundle descriptions and it should be straightforward to capture the digraph alongside the state dump.Ok, so I'm convinced that the region digraph is pulling its weight and isn't a bunch of YAGNI. But someone challenged me the other day by asking "Why do the framework hooks have to be so complex?".Unnecessary Complexity?Well, firstly the region digraph ensures consistent behaviour across the five framework hooks (bundle find, bundle event, service find, service event, and resolver hooks), especially regarding filtering behaviour, treatment of the system bundle, and transitive dependencies (i.e. across more than one region connection). This consistency should lead to fewer bugs, more consistent documentation, and ease of understanding for users.Secondly, the region digraph is much more flexible than hooks based on a static notion of region membership: bundles may be added to the kernel after the user region has been created, application scoping should be relatively straightforward to rework in terms of regions thus giving scoping and regions consistent semantics (fewer bugs, better documentation etc), and multiple user regions should be  relatively tractable to implement.Thirdly, the region digraph should be an excellent basis for implementing the notion of a multi-bundle application. In the OSGi Alliance, we are currently discussing how to standardise the multi-bundle application constructs in Virgo, Apache Aries, the Paremus Service Fabric, and elsewhere. Indeed I regard it as a proof of concept that the framework hooks can be used to implement certain basic kinds of multi-bundle application. As a nice spin-off, the development of the region digraph has resulted in several Equinox bugs being fixed and some clarifications being made to the framework hooks specification.Next StepsI am writing this while the region digraph is "rippling" through the Virgo repositories on its way into the 3.0 line. But this item is starting to have a broader impact. Last week I gave a presentation on the region digraph to the OSGi Alliance's Enterprise Expert Group. There was a lot of interest and subsequently there has even been discussion of whether the feature should be implemented in Equinox so that it can be reused by other projects outside Virgo.
by Glyn (glyn.normington@spamprotectiondeletethis.yahoo.co.uk) at February 10, 2011 02:43 PM
Donald Smith
Announcing the Second EclipseCon Keynote
Some of the best EclipseCon Keynotes have been when highly technical, very smart people, who write great code, speak about projects they are passionate about.In that theme, I'm pleased to announce our Second EclipseCon keynote - "On Apache Hadoop". Todd Lipcon has agreed to come give an in depth look at "big data", something that I know many of us in the Eclipse Ecosystem are bumping into regularly. Our own experiences trying to analyze the UDC data from Eclipse has shown what a challenge this can be.EclipseCon is March 21-24 at the Santa Clara Convention Center (and Hyatt!) Early bird registration is just a couple days away, so register now! - Don
by Donald Smith (noreply@blogger.com) at February 10, 2011 02:40 PM
Neil Bartlett
Solving OSGi "Uses" Constraint Violations
One of the thornier deployment problems we sometimes come across in OSGi is the dreaded “uses constraint violation”. I recently helped a client to solve one of these, and it occurred to me to document the problem and the approach to solving it.
Be warned that this post is quite long and boring. You may not want to read it all right now, but perhaps Google will bring you back here when you first encounter a uses-constraint violation in the wild.
What is a Uses Constraint Anyway??
You may have already read Glyn Normington’s excellent article, which goes into quite a bit of depth on the subject, but regretably without the assistance of pretty pictures, so if you are a visual thinker like me then you might find the following explanation more accessible.
Starting with the basics, in OSGi we have dependencies based on Java packages. Some bundle exports a package, possibly with a version number, and another bundle imports it, possibly specifying an acceptable range of versions:
This notation is borrowed from the OSGi specification: a black rectangle is an export and a white rectangle is an import. The surrounding yellow blobs are bundles. The line between the export and the import means that OSGi has chosen that specific export as a match for the import — they have been “wired” together. So B imports package foo (version 1.0) from A.
Let’s build this up. Suppose bundle B, in addition to importing package foo 1.0, also exports package bar (the version of bar is unimportant). The C bundle imports package bar and gets wired to B:
So far so good. Now let’s complicate things a bit more: let’s say that bundle C, in addition to importing package bar, also imports package foo… BUT it imports version 2.0. Wait, we don’t have foo version 2.0! Never fear, there’s another bundle that does export foo 2.0. We’ll call him D:
Are you surprised that this works? Perhaps not, you may have heard that OSGi supports multiple versions of the same library at the same time, and here it is in action. However there are limits: while we can have multiple versions of the foo package, we must still be able to construct a consistent “class space” for each bundle that has exactly one version of every class. The “class space” for bundle C is shown by the shaded blue area:
Notice how the shaded area avoids the import of foo inside bundle B. This is only possible if the package bar exported by B has no internal dependency on foo does not “expose” foo via its signature (thanks to BJ for this correction).
Exposing foo means that a type in foo is visible through the signature of a type in bar, for example:
code class="java"span class="kn"packagespan span class="n"barspanspan class="o";span
span class="kn"importspan span class="nn"foo.Foospanspan class="o";span
span class="kd"publicspan span class="kd"classspan span class="nc"Barspan span class="kd"extendsspan span class="n"Foospan span class="o"{span span class="c1"// exposure via subclassingspan
span class="kd"publicspan span class="n"Foospan span class="nf"getFoospanspan class="o"();span span class="c1"// exposure via method return typespan
span class="kd"publicspan span class="kt"voidspan span class="nf"setFoospanspan class="o"(spanspan class="n"Foospan span class="n"foospanspan class="o");span span class="c1"// exposure via method parameterspan
span class="o"}span
code
If package bar does expose package foo, as in this example, then we have a “uses constraint”. We illustrate this with a little rubber band, like so:
Now bundle C cannot be resolved. The rubber band means we cannot exclude the import of foo 1.0 from the blue shaded area, i.e. C’s class space must contain foo 1.0. But it is not allowed to contain both foo 1.0 and foo 2.0, so C’s second import cannot be satisfied.
I hope this is clear enough, but I’m sure you’re wondering: how the hell do I fix this? We should certainly avoid tempting runtime options that turn off the uses constraint validation. Neither should we start mucking about trying to “fix” the manifests of third-party bundles. Both of these are hacks that only mask the problem. After all, package bar in bundle B really does depend on a specific version of foo, so we shouldn’t blindly force it to use a different version.
In this example the proper solution is to find an alternative provider of the bar package, one that is compatible with foo 2.0. For example maybe there is a bar version 2.0 available somewhere, that happens to be compatible with foo 2.0. We may need to change the import in bundle C to make sure it gets bar 2.0. If bundle C is our own bundle then this is a reasonable change to make.
How About a Real Example?
Good idea! Let’s move away from foos and bars and look at a real uses-constraint problem. We’ll take the specific example of the client I mentioned: he was trying to use Apache ActiveMQ from an Eclipse RCP application. In the RCP application bundle there was a single import of the org.apache.activemq package. At runtime the RCP bundle failed to resolve with the following error:
code class="text"!MESSAGE Bundle org.example.rcp.activemq_1.0.0.qualifier [37]
was not resolved.
!SUBENTRY 2 org.example.rcp.activemq 2 0 2011-02-08 14:45:37.513
!MESSAGE Package uses conflict: Import-Package: org.apache.
activemq; version="5.4.2"
code
Here we see the most frustrating aspect of uses-constraint violations: the almost total lack of information about the cause of the problem! We need to put our detective hat on.
Our bundle, org.example.rcp.activemq, is failing to resolve because it cannot import package org.apache.activemq version 5.4.2. That package exists, it is exported by bundle number 33, org.apache.activemq.activemq-core:
code class="text"osgi gt; packages org.apache.activemq
org.apache.activemq; version="5.4.2" lt;org.apache.activemq.activemq
-core_5.4.2 [33] gt;
code
The uses constraint violation tells us that something used by the package org.apache.activemq clashes with something else that is imported into our bundle. We can look at the imports of the ActiveMQ bundle:
code class="text"osgi gt; bundle 33
...
Imported packages
javax.annotation; version="1.0.0" lt;com.springsource.javax.annotation...
javax.jms; version="1.1.0" lt;org.apache.geronimo.specs.geronimo-jms_...
javax.management; version="0.0.0" lt;org.eclipse.osgi_3.6.1.R36x_...
javax.management.j2ee.statistics; version="1.1.0"
lt;org.apache.geronimo.specs.geronimo-j2ee-management_1.1_...
javax.management.openmbean; version="0.0.0" lt;org.eclipse.osgi_...
javax.management.remote; version="0.0.0" lt;org.eclipse.osgi_...
javax.naming; version="0.0.0" lt;org.eclipse.osgi_...
javax.naming.directory; version="0.0.0" lt;org.eclipse.osgi_...
javax.naming.event; version="0.0.0" lt;org.eclipse.osgi_...
javax.naming.spi; version="0.0.0" lt;org.eclipse.osgi_...
javax.net; version="0.0.0" lt;org.eclipse.osgi_...
javax.net.ssl; version="0.0.0" lt;org.eclipse.osgi_...
javax.security.auth; version="0.0.0" lt;org.eclipse.osgi_...
javax.security.auth.callback; version="0.0.0" lt;org.eclipse.osgi_...
javax.security.auth.login; version="0.0.0" lt;org.eclipse.osgi_...
javax.security.auth.spi; version="0.0.0" lt;org.eclipse.osgi_...
javax.sql; version="0.0.0" lt;org.eclipse.osgi_...
javax.transaction.xa; version="0.0.0" lt;org.eclipse.osgi_...
javax.xml.parsers; version="0.0.0" lt;org.eclipse.osgi_...
org.apache.commons.logging; version="1.1.1" lt;jcl.over.slf4j...
org.apache.kahadb.index; version="5.4.2"
lt;org.apache.activemq.kahadb_5.4.2 [30] gt;
org.apache.kahadb.journal; version="5.4.2"
lt;org.apache.activemq.kahadb_5.4.2 [30] gt;
org.apache.kahadb.page; version="5.4.2"
lt;org.apache.activemq.kahadb_5.4.2 [30] gt;
org.apache.kahadb.util; version="5.4.2"
lt;org.apache.activemq.kahadb_5.4.2 [30] gt;
org.osgi.framework; version="1.5.0" lt;org.eclipse.osgi_...
org.w3c.dom; version="0.0.0" lt;org.eclipse.osgi_...
org.xml.sax; version="0.0.0" lt;org.eclipse.osgi_...
org.w3c.dom.traversal; version="0.0.0" lt;org.eclipse.osgi_...
javax.xml.stream; version="0.0.0" lt;org.eclipse.osgi_...
...
code
Wow, quite a long list, and I’ve not even included the optional imports! In the worst case we need to review all of these, and then possibly the transitive dependencies of the bundles that export those packages, in order to find the conflict. Nightmare! Fortunately there is a shortcut we can take.
Recall the conflict in the simplistic example arose because there were two versions of the foo package available. This is a necessary precondition for a uses constraint violation, and it gives us a really big clue:
Look for packages that have more than one exporter.
I’d like to be able to say that I jumped straight to the answer at this point, but truthfully I hummed and hawwed a bit first (oh well, it was billable time). I speculated that there might be two copies of the Commons Logging APIs, so I asked the OSGi shell:
code class="text"osgi gt; packages org.apache.commons.logging
org.apache.commons.logging; version="1.1.1" lt;jcl.over.slf4j_1.6.1 [31] gt;
org.apache.activemq.kahadb_5.4.2 [30] imports
org.apache.activemq.activemq-core_5.4.2 [33] imports
code
Nope, just one export, and it’s imported by both org.apache.activemq.kahadb and org.apache.activemq.activemq-core. No problem there.
Then I realised: we’re running on Java 6! That’s significant because Java 6 gratuitously added a bunch of APIs to the base JRE library… APIs that were previously available as optional libraries. This is a rich seam of duplication! So my next guess was javax.xml.stream:
code class="text"javax.xml.stream; version="0.0.0" lt;org.eclipse.osgi_3.6.1.R36x_... [0] gt;
org.eclipse.ui_3.6.1.M20100826-1330 [2] imports
org.eclipse.core.expressions_3.4.200.v20100505 [7] imports
org.eclipse.ui.workbench_3.6.1.M20100826-1330 [10] imports
org.eclipse.core.runtime_3.6.0.v20100505 [11] imports
org.eclipse.help_3.5.0.v20100524 [23] imports
org.apache.activemq.activemq-core_5.4.2 [33] imports
code
Again no. Cutting to the chase, the culprit was javax.annotation:
code class="text"javax.annotation; version="0.0.0" lt;org.eclipse.osgi_3.6.1.R36x_... [0] gt;
org.eclipse.ui_3.6.1.M20100826-1330 [2] imports
org.eclipse.core.expressions_3.4.200.v20100505 [7] imports
org.eclipse.ui.workbench_3.6.1.M20100826-1330 [10] imports
org.eclipse.core.runtime_3.6.0.v20100505 [11] imports
org.eclipse.help_3.5.0.v20100524 [23] imports
javax.annotation; version="1.0.0" lt;com.springsource.javax.annotation gt;
org.apache.activemq.activemq-core_5.4.2 [33] imports
code
Bingo! The package is exported by two bundles: the first is the system bundle itself, which is responsible for exporting all the JRE packages (aside from java.*), and this version is being imported by all the Eclipse plug-ins.
The other version is exported by com.springsource.javax.annotation, which is one of the wrapper bundles available from the repository hosted by SpringSource. Our RCP application naturally depends on the Eclipse stuff, therefore it cannot get the ActiveMQ library because of this conflict. Time for another pretty diagram:
How Can This Be Fixed?
Another fine question! In our abstract foo/bar case the solution involved finding a provider of “bar” that was compatible with foo version 2.0.0, and then changing our bundle C to make sure it used that new “bar”. In this case, both ActiveMQ and the Eclipse bundle are third-party binaries that we should not change.
Our goal is to make both ActiveMQ and Eclipse import the same version. ActiveMQ cannot import version 0.0.0 from the JRE, but Eclipse can import version 1.0.0.
But wait a moment, there is no such thing as version 0.0.0 of javax.annotation! It’s nonsense. The OSGi system bundle’s job is to export all of the JRE packages but it has no idea what version numbers to use for those exports. Indeed, nobody knows what the version numbers of all the JRE packages are. There is documentation for some of them, but none of that documentation is normative, and anyway it doesn’t cover everything in the JRE. We really need a JSR or OSGi specification that tells us definitively. Anyhow because of the lack of information, the OSGi framework clumsily exports everything as version 0.0.0.
Therefore the solution involves configuring the OSGi framework in one of the following ways:
Removing javax.annotation from the exports of the system bundle altogether; this will make both ActiveMQ and Eclipse resolve from the SpringSource bundle.
Exporting the javax.annotation package from the system bundle as version 1.0.0; then we don’t need the SpringSource bundle.
Using a special bundle that pulls the javax.annotation package from the JRE (using Require-Bundle!) and reexports it as version 1.0.0.
The first two approaches require us to create a “profile”, i.e. a list of JRE packages, and pass it to Equinox using the osgi.java.profile configuration setting.
The third approach is quite tricky if we have to create the bundle ourselves, but there is an existing bundle in most Eclipse IDE distributions that does exactly this. Unfortunately the bundle doesn’t appear in the RCP target platform downloads, which is why my client went to the SpringSource bundle repository to find a provider for the package and ended up in the mess he was in.
What’s my recommendation? Really I prefer the second option because the third just feels like a hack to me. There is a further issue though: if you use Eclipse PDE and click the “Validate Plug-ins” button in the Run Configuration dialog, then PDE will report a missing import, because it doesn’t know about the JRE profile setting. Clearly a missing feature or even a bug in PDE, but because of this you may prefer the third option.
Another Rant About Require-Bundle
Notice the arrows in the previous diagram, they indicate a Require-Bundle dependency rather than an import/export wiring. It turns out that Require-Bundle is responsible for this uses constraint problem, so I might as well have another rant about it.
The packages command told us that javax.annotation from the JRE was imported by Eclipse core runtime, core expressions, UI, workbench, and help. But I happen to know that none of those bundles actually use the javax.annotation package!! I know this because Eclipse still runs on Java 1.4, where those annotation classes won’t even load. But Eclipse uses Require-Bundle as follows:
code class="text"Require-Bundle: org.eclipse.osgi
code
By requiring the system bundle, Eclipse implicitly imports the entire JRE. This is a terrible idea, and it is only done in Eclipse because of backward compatibility and because the PDE tooling is so inadequate for working with Import-Package dependencies.
(In fact, the uses constraint problem in this example can be solved by switching the RCP plug-in to use Import-Package to get hold of its dependencies on the Eclipse APIs. Sadly PDE makes Require-Bundle so convenient, and Import-Package so inconvenient, that very users are disciplined enough. I admit that even I use it when I’m feeling lazy.)
In my opinion Eclipse 4 should be used as an opportunity to break with the uglier parts of Eclipse’s legacy. It’s admittedly hard to do that when you have an ecosystem of literally thousands of 3rd party plug-ins that would stop running on the new version… but must this crap really be maintained forever? Will Eclipse 5 make the break, or Eclipse 6? A big part of what ails Java itself is the legacy compatibility burden; I hope Eclipse can be bolder.
Anyway, ranting over, here comes the recommendation:
Eradicate Require-Bundle dependencies from your bundles.
Installation Order
Consider the following modification to the original abstract scenario. Bundle B now accepts a range for the foo package: either version 1 or 2. If these bundles are all installed at the same time, then C is now resolvable because both C and B can wire to the version 2.0 foo offered by bundle D:
In this scenario bundle A will be ignored. However now suppose that only bundles A and B are available at startup, with C and D being installed later.
At startup B will resolve to the single version of foo available, which is version 1.0.0 from bundle A. When C and D are installed, C will be unresolvable, since it cannot import bar from B at the same time as it imports foo from D. OSGi tries to keep the existing resolved bundles stable, so it does not force B to rewire its import of foo to the new version.
This behaviour can be counter-intuitive. OSGi never dynamically rewires imports when new bundles are installed, it only tries to find wirings for the newly installed bundles. This is because rewiring is expensive: it can force the shutdown and restart of many bundles, and just calculating all the wirings again takes some time (it is NP-complete).
We can force OSGi to rewire everything by issuing the refresh command at the shell. If we do this, B’s wiring will switch to use foo 2.0 from D, and C will resolve. Therefore to check whether you have a problem with installation order:
Just type refresh and see whether the problem goes away.
Any More General Advice?
Solving a uses-constraint violation requires us to find an accurate diagnosis first, before we attempt to prescribe a cure.
Once the diagnosis is confirmed, seek a cure based on configuring the platform rather than messing with bundle manifests: uses-constraint violations are signals of an invalid deployment, i.e. a set of bundles that cannot work together. They are usually not signs of a development problem to be fixed within the bundles themselves — unless the bundles can be shown conclusively to have inaccurate or invalid manifests.
Regarding diagnosis, a necessary precondition for any uses-constraint violation is multiple exporters of the same package. So the first question to ask ourselves is:
Are there any obvious sources of multiple exports of the same package?
For example, have we included two versions of the same bundle? Are there bundles with overlapping exports?
Using the packages command in the Equinox shell can help to find multiple exporters, and tells us which bundles are using each export.
If running on Java 6, could one of the new JRE packages be the source of the problem?
Here’s a list of all the packages in Java 6 that were not in Java 5:
code class="text"javax.activation javax.xml.crypto.dom
javax.annotation javax.xml.crypto.dsig
javax.annotation.processing javax.xml.crypto.dsig.dom
javax.jws javax.xml.crypto.dsig.keyinfo
javax.jws.soap javax.xml.crypto.dsig.spec
javax.lang.model javax.xml.soap
javax.lang.model.element javax.xml.stream
javax.lang.model.type javax.xml.stream.events
javax.lang.model.util javax.xml.stream.util
javax.script javax.xml.transform.stax
javax.tools javax.xml.ws
javax.xml.bind javax.xml.ws.handler
javax.xml.bind.annotation javax.xml.ws.handler.soap
javax.xml.bind.annotation.adapters javax.xml.ws.http
javax.xml.bind.attachment javax.xml.ws.soap
javax.xml.bind.helpers javax.xml.ws.spi
javax.xml.bind.util javax.xml.ws.wsaddressing
javax.xml.crypto org.w3c.dom.xpath
code
With regard to prescribing a cure, the general approach is to find an alternative bundle or set of bundles that can provide the dependencies we need.
Does an alternative non-conflicting source for the dependency exist?
If JRE packages are involved, can the additional exporters be removed? Try specifying package versions in the Java profile.
If the JRE is not involved and no alternative supply of the dependencies can be found, then maybe these bundles really cannot be used together: they are simply incompatible. This is bad news to be sure, but it’s better to find it out early from the OSGi resolver than from weeks of debugging a misbehaving runtime.
Does It Really Have to Be This Hard?
I hope not! Clearly this kind of analysis is still based on too much in-depth knowledge of OSGi’s internal workings, which puts it beyond the capabilities of most developers. This could be a real problem for adoption of OSGi in complex enterprise applications.
As ever, we need better tools. My dream is to create tooling in Bndtools that will help to quickly diagnose and offer fixes for problems like this. Here I’d like your suggestions… what kind of tooling would help?
I’m thinking about some kind of graphical tool that can build diagrams on the fly similar to those in this blog post, including the “class space” visualisation. My concern is that it might not scale to a realistic scenario: perhaps the diagrams would just be too big and complex to be any use. I’m just not sure at this point.
Anything Else to Say?
Yes: well done for making it all the way through, and happy hunting. p
February 10, 2011 05:45 AM
February 09, 2011
Nick Boldt
Simplifying The p2 Process, Part 2: Target Platform Repos
In Part 1 of this series, I looked at use of composite repos to provide a way of combining update sites into a single URL for ease of use and a single point of entry from which to do updates.
Defining a Target
Now, I'd like to talk about how to escape the proliferation of zips needed to establish a target platform. For those unfamiliar with the term "target platform", it's either the installed base against which you're compiling your code, or it's the collection of things you have to install first before you can install something on top of that.
For the JBoss Tools case, we have at least 8 prereqs for installation. Here's what you had to install prior to JBoss Tools 3.1.1:
Now, admittedly, because there is also the Ganymede update site, you don't necessarily need to download and unpack all these zips in order to install JBoss Tools - instead, you need only enable the Ganymede site. (Same story for Helios and JBoss Tools 3.2.)
However, to do a reproduceable PDE-based build, you still need to create this base install. Traditionally, PDE's approach was to download and unpack these zips into the root of the Eclipse install running the build. Athena attempted to improve on this situation by allowing you to define a list of update sites and IUs (features and/or plugins) which were needed to define the platform. But it was far from portable, and hardly reusable.
Buckminster (later b3) also approached this problem by creating its own markup for defining what sites and what IUs to install, backed by an EMF model. But rather than dealing with a UI to create the model and populate it, I found it more useful to simply generate an instance of the aggregator model and then use the aggregator to fetch amp; install IUs. But as the aggregator is simply a wrapper for the underlying p2.mirror and p2.director tasks, you can use those directly too.
But as they say... "Don't bore us, get to the chorus!" So, here's some sample code for the various solutions for build-time provisioning.
Using the buckminster aggregator (properties file) - stopped working for us w/ Eclipse 3.6, so we switched to b3
Using the b3 aggregator (properties file) - stopped worked consistently due to network timeouts resolving deps amp; fetching IUs.
Using p2.mirror - underlying p2 ant task for mirroring from one or more repos to local disk
Using p2.director - underlying p2 ant task for installing IUs (from local or remote repo) into some target Eclipse
So, with these tools, you could create a p2 repo from other repos - mirroring and installing IUs as needed - and even script an installation. But was there a better way?
Target Platform Definition File
Enter the target platform definition file (.target). This file contains a list of IUs and the p2 repos from which to provision them. So, it's like a b3 aggregator model, or an Athena build.properties file, but abstracted away from the concept of a build, because it can be used for building but ALSO for provisioning a user's installed Eclipse base.
Unfortunately, the Target Platform Definition File editor in Eclipse 3.6 is less than optimal for large targets, or when your internet connection is suboptimal. So, after fighting with it for a while, filing bugs, and ultimately giving up, I went back to my handy-dandy XML editor (often just vim) to maintain it more simply. So rather than having Eclipse automatically install things based on a .target file, I revert to a workflow that actually works: installing by hand from an update site.
While Buckminster does support .target files (or so I've read), I didn't want to be dependent on it any more, preferring a more "pure" solution.
So, based on code from Peter Nehrer (@pnehrer), I then wrote an XSL transform to create a p2.mirror script from a .target file, wrapped with another Ant script (and optionally, a Maven pom.xml script).
And why might you care? Well, this .target file can be used to:
Provision a developer's Eclipse, using the Target Platform Definition Editor and a few clicks (when it doesn't time out)
Provision a developer's Eclipse via script for offline or multiple users (getting the team up to speed)
And yes, much (or all) of the above can be done w/ Buckminster and/or b3, if you like that approach.
But I prefer to create the .target as input to a build process, rather than being explicitly tied to one. So, as I noted above, if you have a .target file, you can easily generate a p2 repo, and use that repo to run downstream builds. Now, instead of having a half-dozen zips to download and unpack with every build (using the deprecated and unsupported "dropins" method) you can use a fully-p2-friendly repo site which contains everything you need to do your builds - whether you're a Hudson server or a developer working at home or offline.
Benefits
Unlike "a collection of zips" this single-source-site can be versioned with each release.
It only contains WHAT YOU ACTUALLY NEED rather than extraneous sources and doc and tangential plugins/features you don't. It's a bit like making muffins by first grinding your own flour, but at least you know there's nothing evil in that muffin mix, and you will be able to consistently reproduce the recipe every time, regardless of where you might be on teh interwebz.
f you're a keener / beta tester who likes to build against the latest milestone (or even a weekly integration build) of Eclipse 3.next or 4.future, you can use the script above to self-update. So, while the TP itself is a contained snapshot listing the explicit versions of feature groups needed, it can also be run in "get the latest available" mode in order to keep your TP current against some HEAD or trunk development / releases.
By splitting the TP out of the build, you can build it upstream. So, where in the past we had one "uberbuild" and an implied TP therein, now we have a TP build job, and it is then shared by the 34 downstream jobs which depend on it for their dependencies.
Shut up and show me the code!
# for the "foo.target" file, build a local target platform repo, fetching the latest versions and updating the .target file
$ ant -f build.xml -DtargetFile=foo.target -DuseLatest=true
# for the "bar.target" file, build a local target platform repo, but fetch only the stated versions of IUs
$ ant -f build.xml -DtargetFile=bar.target -DuseLatest=false
That's it. I also wrap the build.xml ant script w/ a pom which allows it to be called from an upstream Maven/Tycho process, but that's nothing more than just calling the script using the antrun plugin (and a few ant dependencies), like this:
lt;build gt;
lt;plugins gt;
lt;plugin gt;
lt;groupId gt;org.apache.maven.plugins lt;/groupId gt;
lt;artifactId gt;maven-antrun-plugin lt;/artifactId gt;
lt;version gt;1.6 lt;/version gt;
lt;executions gt;
lt;execution gt;
lt;phase gt;validate lt;/phase gt;
lt;configuration gt;
lt;tasks gt;
lt;ant antfile="build.xml" gt;
lt;property name="targetFile" value="multiple.target" / gt;
lt;!-- lt;property name="repoDir" value="/path/to/where/to/provision/repo"/ gt; -- gt;
lt;/ant gt;
lt;/tasks gt;
lt;/configuration gt;
lt;goals gt;
lt;goal gt;run lt;/goal gt;
lt;/goals gt;
lt;/execution gt;
lt;/executions gt;
lt;dependencies gt;
lt;dependency gt;
lt;groupId gt;commons-net lt;/groupId gt;
lt;artifactId gt;commons-net lt;/artifactId gt;
lt;version gt;1.4.1 lt;/version gt;
lt;/dependency gt;
lt;dependency gt;
lt;groupId gt;org.apache.ant lt;/groupId gt;
lt;artifactId gt;ant-commons-net lt;/artifactId gt;
lt;version gt;1.7.1 lt;/version gt;
lt;/dependency gt;
lt;dependency gt;
lt;groupId gt;org.apache.ant lt;/groupId gt;
lt;artifactId gt;ant-trax lt;/artifactId gt;
lt;version gt;1.7.1 lt;/version gt;
lt;/dependency gt;
lt;/dependencies gt;
lt;/plugin gt;
lt;/plugins gt;
lt;/build gt;
The rest of the code is here.
In part 3, I'll look back at the success we've had using associate sites instead of asking people to manually add 3rd party URLs when installing JBoss Tools. SPOILER ALERT: one URL is easier for people to use than 6.
In part 4, I'll talk a little about how to prevent your product build from getting updates from unofficial sources, and preload your product with the official sites from which to get updates. Because it's important to balance ease of use with prevention of unsupported features. SPOILER ALERT: may contain p2.inf instructions. p
by nickb (nickboldt@gmail.com) at February 09, 2011 11:39 PM
Jeff McAffer
Help us make Peter cry…
Unknowingly, today Peter Kriens issued a challenge — to make him cry. In his post Peter extolled the virtues of the up coming OSGi DevCon and EclipseCon conference. Referring to the talk from me and Paul VanderLei, he said:
If you want to be really entertained then the 10 signs you’re doing OSGi wrong by Jeff McAffer (EclipseSource) and Paul VanderLei (Band XI International) is always highly recommended. Two years ago I almost had tears in my eyes and I actually also learned a few things.
This was high praise (thanks) but also a challenge! ”almost” Why almost?!  Clearly we can do better than almost.
We need to make Peter cry and we need your help.
In our talk at EclipseCon 2011 Paul and I are taking a light-hearted look at the mythology that surrounds OSGi and pointing out some of the warning signs that something is amiss in your project. One of our goals is to make this concrete with real code confessing the sins of real authors. To be sure, some of our own misguided practices will be unveiled but OSGi is an open community so it makes sense that your sins be included to.
You can help make this educational and interesting by sending us pitfalls and bad practices that you and your colleagues have encountered or committed. Preferably with code snippets or concrete examples.
Please comment on this post with pointers to problems or practices that you think are particularly nasty or subtle.  We will combine these examples (either anonymously or with, errr, “attribution” as you choose) with a humorous take that will make Peter fall off his chair crying.
See you at EclipseCon…
p
by jeff at February 09, 2011 09:05 PM
Doug Clarke
JPA 2.0 in WebLogic with OEPE
To add to my previous post. Greg Stachnick has posted the steps for enabling JPA through the Oracle Enterprise Pack for Eclipse.Doug
by Doug (noreply@blogger.com) at February 09, 2011 08:58 PM
Mike Milinkovich
Eclipse Foundation Elections
Just in case you hadn’t noticed, the nominations are in, and the “campaign” phase of our 2011 Board of Director elections in now in full swing.
I have to say that I am particularly impressed with the quality of the candidates this year. There are a lot of well-known and well-respected community leaders who have thrown their hats into the ring. Every one of them should be commended for volunteering their time and energy to improving the Eclipse community and its governance.
The Eclipse Foundation has a unique governance model in the open source world, and one which I believe works extremely well. As I recently commented on the OpenJDK governance conversation:
The Eclipse Board explicitly has a mix of business-centric and community-centric representatives on it. In practice, it has actually worked well because the diversity of views have generally speaking resulted in better decisions. Diversity takes many forms, but it is almost always a force for good.
The people running in this election are your community-centric representatives. They have an enormously positive influence on the Board’s decisions, and the elected directors past and present have been a big part of our collective success.
I strongly encourage everyone within the Eclipse community to check out the candidates pages, ask questions on the foundation forum and vote in the coming weeks!
Filed under: Foundation p
by Mike Milinkovich at February 09, 2011 08:47 PM
Erwin Tenhumberg
In Eclipse - Maven learns Event Insight
How-to setup your SAP Business Objects Event Insight development environment in three easy steps. We all know the general rule -- If you type something twice you already missed the first chance to write a script for it. The same is true if you ever tried to create an Event Insight Java project. But of course there is a workaround that allows you to use the mighty powers of maven to create a simple but powerful built environment. This is a step-by-step guide that leads you to a compiling, working, and running SAP Business Object Event Producer using the powers of maven.
by Sebastian Steinhauer at February 09, 2011 06:34 PM
Ralf Ebert
Applitude 0.3 released: iPhone DSL and framework
applitude is an Objective C runtime framework and an Eclipse Xtext domain-specific language for iPhone application development. The DSL is an extended, iPhone-only version of the Applause project.
Applitude allows to describe commonly used elements of iPhone applications in a very dense, made-to-measure language. It simplifies many aspects of developing iPhone applications, like doing HTTP requests, parsing JSON/XML data, showing activity indicators while the app is loading, feeding data into tables when it gets available, handling errors, caching, etc. This is an application built in around 80 lines of applitude:
It comes with Eclipse IDE tooling that can be installed from the Eclipse marketplace:
Learn how to get started at: http://applitude.org/
What’s new?
I just released version 0.3 of applitude. This is new:
IDE: There is a wizard now to create new projects (including the Xcode project), see Creating a new project (#12):
IDE: The editor features now content assist proposals for for, cell, section, tableview (#31)
DSL: selects for contentprovider can now be omitted and is actually supported (#40):
codecontentprovider Inventors returns Inventor[]
fetches JSON from "http://applitude.org/demo/inventors.json"
selects "data.allInventors"code
DSL/Runtime: contentprovider ... fetches XML is now fully supported via runtime component ContentProvider+XML. The inventors demo shows boths JSON and XML now #51. Example for XML content provider:
codecontentprovider AllInventorsXML returns Inventor[]
fetches XML from "http://applitude.org/demo/inventors.xml"
selects "/inventors/inventor"code
Runtime: Components were restructured ContentProvider, ContentProvider+JSON, ContentProvider+URL, ContentProvider+XML, Tables, Actions, Bindings and to utility classes in Utils (#21, #46).
Generator: All expressions defined by the DSL language are now supported by the generator. Along the way, the generator templates/extensions were cleaned up a lot. Check Reference gt; Expressions in demo.applitude for expression examples:
DSL/Generator: Views and ContentProvider support passing multiple parameters now (#56, #57):
codecell {
action: InventionDetail(inventor, invention)
}
tableview InventionDetail(Inventor inventor, Invention invention) {
...
}code
Generator: Regular views are supported as application view now, UINavigationController is instantiated automatically (#20)
p
February 09, 2011 04:45 PM
Ralf Ebert
Applitude 0.3 released: iPhone DSL and framework
applitude is an Objective C runtime framework and an Eclipse Xtext domain-specific language for iPhone application development. The DSL is an extended, iPhone-only version of the Applause project.
Applitude allows to describe commonly used elements of iPhone applications in a very dense, made-to-measure language. It simplifies many aspects of developing iPhone applications, like doing HTTP requests, parsing JSON/XML data, showing activity indicators while the app is loading, feeding data into tables when it gets available, handling errors, caching, etc. This is an application built in around 80 lines of applitude:
It comes with Eclipse IDE tooling that can be installed from the Eclipse marketplace:
Learn how to get started at: http://applitude.org/
What’s new?
I just released version 0.3 of applitude. This is new:
IDE: There is a wizard now to create new projects (including the Xcode project), see Creating a new project (#12):
IDE: The editor features now content assist proposals for for, cell, section, tableview (#31)
DSL: selects for contentprovider can now be omitted and is actually supported (#40):
codecontentprovider Inventors returns Inventor[]
fetches JSON from "http://applitude.org/demo/inventors.json"
selects "data.allInventors"code
DSL/Runtime: contentprovider ... fetches XML is now fully supported via runtime component ContentProvider+XML. The inventors demo shows boths JSON and XML now #51. Example for XML content provider:
codecontentprovider AllInventorsXML returns Inventor[]
fetches XML from "http://applitude.org/demo/inventors.xml"
selects "/inventors/inventor"code
Runtime: Components were restructured ContentProvider, ContentProvider+JSON, ContentProvider+URL, ContentProvider+XML, Tables, Actions, Bindings and to utility classes in Utils (#21, #46).
Generator: All expressions defined by the DSL language are now supported by the generator. Along the way, the generator templates/extensions were cleaned up a lot. Check Reference gt; Expressions in demo.applitude for expression examples:
DSL/Generator: Views and ContentProvider support passing multiple parameters now (#56, #57):
codecell {
action: InventionDetail(inventor, invention)
}
tableview InventionDetail(Inventor inventor, Invention invention) {
...
}code
Generator: Regular views are supported as application view now, UINavigationController is instantiated automatically (#20)
p
February 09, 2011 04:11 PM
Peter Kriens
OSGi DevCon/EclipseCon 2011, Did you Register Yet?
This is the last week you can register with the early registration discount, so you better get your socks on! And you should register because we have been able to build (again) a very interesting program. This years we even had BJ Hargrave make a video to convince us to pick his presentation.A first this year is an introduction to OSGi by yours truly. Though virtually all developers on EclipseCon
by Peter Kriens (noreply@blogger.com) at February 09, 2011 04:10 PM
Ian Skerrett
Two Reasons Why Nuxeo’s New Project Is Important
Today, Nuxeo announced they would like to start a new open source project at the Eclipse Foundation, based on their existing Nuxeo Core technology.   We always like getting new and interesting project proposals but I think this one is important for two reasons:
1) Foundation for innovation.   As Matt Aslett has written, more and more companies are seeing the benefits of community led projects, rather than having direct corporate control of the project.    Eric Barroca, CEO of Nuxeo, also stipulates one of the reason for proposing the project is to engage with the community to foster innovation.
Nuxeo is a well established player in the enterprise content management space, with a solid business model that allows them to build value on top of a widely deployed platform.   Having Nuxeo look to Eclipse as being a place to take their strategy to the next level is a  great validation of the Eclipse model.
2) More options for the Eclipse RT and the stackless stack.  The Eclipse community has been expanding the EclipseRT technology portfolio.   Last year projects like Virgo and Gemini have accelerated the technologies available for building runtime stacks.   Nuxeo Core is based on OSGi and run on Equinox and Virgo.   Having a Content Repository project at Eclipse will add to the functionality available for people who want to assemble their own runtimes.   This is an important addition for the EclipseRT portfolio.
The new Eclipse Enterprise Content Repository Project (ECR) will be one to watch.   More details and information are available from Eric’s blog post.
p
by Ian Skerrett at February 09, 2011 02:47 PM
Alex Blewitt
Someday ...
Someday, all software will be built this way.
I've been a fan of Git for a while now; I've written a few Git posts in the past including the explanatory Git for Eclipse users post, which explains the key differences between DCVS and CVCS.
I've also been using Gerrit for a while via the EGit review page at Eclipse. Gerrit is a code review system, based on the features that a DVCS gives you. If going Git is the main course, then Gerrit is the dessert; with Jenkins being the cherry on top.
Code review systems generally fall into one of two categories, which have advantages and disadvantages:
Pre-commit reviews, in which a diff attached to a review system
Advantage: avoids polluting the version control system with versions which may be inaccurate or may not make it
Disadvantage: committed code post review may not exactly match the proposed change
Post-commit reviews, in which the change is committed and then later blessed
Advantage: ensures that exactly that change is part of the version history
Disadvantage: potentially pollutes the version control system with changes which need amendment or may have to be rewritten or aborted
There are of course other approaches, such as the man-in-the-middle commit (such as used by Eclipse, where patches are uploaded as attachments to a bug review system and then committed, possibly with changes, by a separate committer). However, this approach tends to work with open-source systems; and it doesn't solve the problem of committers (with write access) having their changes reviewed. In fact, the patch-attach tends to go stale far quicker than review systems.
Branches are the way forward
So how does DVCS help here? Well, the key problem with review-after-commit is not so much that the change exists in the version control system, but rather most implementations use review-after-commit-to-HEAD(trunk). As such, one bad code commit causes subsequent code commits to be invalidated, or at least, contain code which can't be easily undone (other than by committing a reverse patch).
The solution, therefore, is to use branches. If you commit onto a branch, you don't affect any developers on HEAD(trunk). The branch can be reviewed independently, suggestions or improvements made, checked against a build system, and then finally merged onto HEAD(trunk) post-review. Of course, if you have two concurrent changes, you need two branches. And if you have a team of ten developers, you need 10(*2) branches. Go down this road for any sensible amount of time and you quickly realise that you need one branch per change, so that no changes interfere with another.
Of course branches bring about merges (and merge conflicts), so using a tool which is implicitly based around branches and merging is a no-brainer. So using Git (or Hg), you can develop changes on a local branch, push that branch to a central warehouse, ask others to review it, and then merge exactly that change onto master(HEAD, trunk). Even better, since it's a DVCS, that merge commit will have the full history of the change (including the sign-off) so someone can say "Alex approved 01b3cd" and you know exactly what change that refers to.
There are a couple of variations on this theme in the Git world (Hg users tend not to like re-writing history) which involve 'squashing' the branch (i.e. removing all the intermediary steps and replacing with a single unified diff of the branch) as well as 'rebasing' (moving the diff forward to master (HEAD, trunk) instead of creating a merge node (which joins together two otherwise unrelated Git trees). The different configurations here don't really affect the way that the review-after-commit-and-merge works; when you bless that code, you bless that code.
Enter Gerrit
Gerrit is a review-based tool which operates on a Git repository. (There's nothing significant that would prevent a tool like Gerrit working on Hg; but like GitHub, innovations tend to happen faster with Git.) The way Gerrit works is by being a process-in-the-middle between your local Git repository and the 'blessed' central Git repository. Once you use it, it's common for Gerrit to become the de-facto owner of the Git repository that it fronts; though since DVCSs don't have an enforced centralised Git repository as such, this can be changed if desired. It is common (in organisations replacing legacy version control systems such as CVS and SVN) to have a centralised server to host source data, which may be on higher-resiliency and backed-up hardware; so the central Gerrit instance can be an advantage for those looking to make the switch.
You configure Gerrit as a remote repository, much like you would with any other. In fact, you can use it as the only remote repository, by cloning from it initially. The EGit project, for example, is available via ssh://iusernamei@egit.eclipse.org:29418/egit.git, although it's faster to clone/pull from the unauthenticated http://egit.eclipse.org/egit.git, which is the same underlying on-disk data.
To push changes to Gerrit, you configure a remote based on the authenticated access. You also don't push to refs/head/master (which is the Git synonym for HEAD or trunk) as you might if it was a standalone Git repository; rather, you push to refs/uforu/master, or for refs/for/other if you want to submit a different branch. You can configure it with a wildcard, so any local branch can be pushed:
git config remote.review.url ssh://username@egit.eclipse.org:29418/egit.git
git config remote.review.push refs/heads/*:refs/for/*
The refs/for/master acts like a PUT request; there isn't a single branch with that name, but rather, each push to refs/for/master results in the creation of its own unique branch. In the case of EGit change I1c5ec794, the temporary branch allocated was refs/changes/46/2446/1. Other changes have their own branch; EGit change Ie639e366 corresponds to branch refs/changes/47/2447/2. (The 2 at the end in this case indicates the second version of the change; though this is a Gerrit specific notation. The first two digits are merely a directory discriminator based on the last two numbers of the change, so it contains 47/2347/*, 47/2247/* and so on.)
Once the change is in the DVCS, it's possible to generate diffs or any other kind of processing with standard Git tools. Not only that, because it's on a publicly accessible remote DVCS server, you can even checkout that particular changeset. Gerrit even helpfully contains the command needed to do that in the web page:
git fetch http://egit.eclipse.org/r/p/egit refs/changes/47/2347/2 amp; amp; git checkout FETCH_HEAD
This makes it possible to bring a proposed change down, run tests or any other kind of processing on it. In fact, to make it really easy, the above change implements a “fetch from Gerrit” action in Eclipse, which permits you to check out a change and create a local branch from it.
By this point, you may well be thinking Gerrit sounds like a handy review tool. As well as storing changes, you can review the diffs, comment on files on a file-by-file or even line-by-line basis as well as on the review as a whole. But it also stores review flags, which can include the standard kind of +1 and -1 votes. By default, it needs each change to be reviewed to get a +2 review change vote, though this can be configured.
There's also a +1 and -1 “Verified” flag, which was introduced to support Android development (which uses Git and Gerrit). The purposes of Verified is to ensure that the code compiles and passes its test suite, rather than the code-review which is general sanity.
Enter Jenkins
Jenkins is a continuous integration server with a short history but a tumultuous past. As a continuous integration server, it can check out and execute builds, run tests and mail results. If you're used to continuous integration servers, you may have seen the ability to check for changes via the SCM and kick of builds automatically.
Jenkins is designed to permit arbitrary triggers to kick off builds. This can include timed triggers (nightly), by polling an SCM for changes, or by many other means. Normally, a triggered build will just kick off a build based on a specific branch (e.g. master).
The Gerrit Trigger allows you to kick off a build when a new review in Gerrit is posted. Not only that, but it will also check out exactly the proposed change, compile it, and run all the tests – automatically. When it finishes successfully, it can post a +1 Verified (or -1, if it fails). All of this can happen before the reviewer has even had time to see your change, so that if the change causes a build failure, it can be rejected automatically.
In addition, there's a Git Plugin that can be used to tag the build and push changes up to the remote repository, so there's a persistent record of the change having successfully been built.
It's interesting that Kim Moir has posted on the Eclipse build process as well today. It looks like Hudson will be a key part of that, and the Jenkins and Hudson plugins are compatible (for the time being, at least). But if Eclipse is going to move over to Git full-time, then Gerrit will effectively become mandatory, either on Eclipse hardware or managed by individuals on behalf of specific teams.
Submission
So once a change has been pushed to Gerrit, automatically built and tested, flagged as verified, and reviewed by a couple of other developers, the change is good to go. Since Gerrit has all the information, it can apply the change to the master branch on the user's behalf.
Merging the branch can take a number of different forms; cherry-pick allows you to write the change on top of master, merge will create a merge node, and fast-forward requires the patch be 'up-to-date' before being committed. Either way, the contents of the master version control branch always go through a review and test process, whilst it's possible to guarantee that the changes merged are exactly the ones approved.
Conclusion
Once you go Git, you don't go back. Once you go Gerrit, unreviewed code becomes unthinkable. And once you go Jenkins, you don't even need to compile and test the code yourself. Someday, all software will be built this way.
p
by AlBlue (noreply@blogger.com) at February 09, 2011 08:35 AM
February 08, 2011
Mik Kersten
Prediction #5: Open source ALM tools continue to gain market share, give the development manager a migraine
The influence of open source on software development is often measured by the impact of successful libraries and frameworks. It’s hard to imagine building a modern web application without open source components. A similar trend is now unfolding in the Application Lifecycle Management (ALM) space, driven by tools created by projects needing to support their own open source software delivery. While ALM tools are often associated with the heavyweight workflow characteristics of enterprise application development, successful open source projects are a great example of the transformation underway in ALM, towards lean methods and lightweight, developer-centric tools.
In contrast with the application development tools which we use for writing and debugging code, ALM tools assist us with an application’s evolution over time. At their core, ALM tools track tasks and changes, help manage builds and releases, and support the dialogue that defines an application’s evolution. This subset of ALM is sometimes referred to as Application Development Management (ADM). On top of this core feature set layer tools for project and product management. Large organizations add additional tools to the stack to handle program and project portfolio management.
Thanks to a combination of resource constraints, a preference for using open source technologies for open development, and the common desire for developers to sharpen and extend their own toolset, the past decade has delivered a critical mass of the open-source ALM tools. Consider the scale of ALM on Eclipse.org: 33M lines of code in the last coordinated release (733 installable features/components), 330K total Bugzilla reports (3K new each month), 15K Bugzilla users, 1K committers (400 active), 300 projects and 173 Hudson build jobs. Add to that dozens of interdependencies between Eclipse projects and other open source projects such as the popular Apache libraries. ALM on Eclipse is managed entirely with open source tools including Bugzilla, CVS, Git, Hudson, MediaWiki and Mylyn.
The 1,948 respondents to the 2010 Eclipse Community Survey provide an overview of the degree to which open source tools have percolated into commercial software development. Only a small fraction of the survey respondents were directly involved with Eclipse, and half were from organizations with over 100 employees. The striking pattern is that the core open source ALM tools, when combined, have the market lead in each of three key ALM categories visible in the figure below. In 2010 for these categories, open-source ALM has taken the market lead from closed-source solutions. While surveys of this sort are always skewed towards the type of developer who bothers to answer surveys, this result remains indicative of a shift in application development practices and open-source ALM market share. In 2011, I predict that this trend will continue and that open source tools will percolate into the ALM stacks of more conservative organizations. A degree or two of separation from their open source counterparts, many of those developers will not recognize the term DVCS before it is force fed to them.
The attraction to open source ALM is not just price point, but the amount of innovation that has been driven by open source developers building tools to support their own productivity patterns. The ecosystem of extensions that forms around popular open source projects is another key driver of adoption. Those ecosystems are also likely to produce the most interesting integrations, since open source has proven itself as the most effective mechanism for growing both the community and APIs needed for innovative extensions. Finally, organizations with long application and product lifecycles are attracted to open source ALM tools because a suitable open source license gives them confidence that they will be able to access and extend the knowledge base represented by their issue tracker ten years from now, when the landscape of ALM vendors will much different than it does today.
Open source ALM tools are built on developer-centric principles. Transparency is favoured over hierarchy, with every task and bug on Eclipse and Mozilla being editable by anyone. It relies on asynchronous collaboration and a consistent use of the task or issue tracker to capture all discussion relevant to changes in the software. It encourages lining up modularity and framework boundaries with team boundaries, allowing API layers to facilitate dependencies and collaboration. There are also things missing from the stack. Responsiveness to the community often takes precedence over planning, and after the fading away of XPlanner, there has been a distinct gap in project management features within the open source tool space. There is also no single integrated open source ALM stack, instead open source projects glue together their own best of breed solutions, and layer customizations on top, as is the case with the numerous tools built on the Eclipse Bugzilla repository. Integration with product, project and portfolio management tools is typically non-existent, as this is not something that even large open source projects need.
While open-source developers will continue working very happily with their increasingly slick tool set, this impedance mismatch with large-scale ALM implies major problems for organizations who are planning to get a lot of ALM functionality for free. There mismatch between both the toolset and the cultural aspects of open source ALM tools and what’s needed by the enterprise. Agile and lean development have the opportunity to bridge some of the cultural gap, but still have a considerable way to go in order to incorporate the lessons learned from open source. There is enough of a gap in the toolset that organizations already deploying open-source tools at the enterprise ALM scale have needed to set up their own ALM tool engineering teams. These teams create enterprise-level authentication and access control, provide third-party ALM tool integrations, and implement support for features such as linking existing Project Portfolio Management (PPM) tools. Due to the pace of change in open source ALM tools, they are fighting a losing battle. While wasteful, this exercise is currently necessary. Large organizations that fail to integrate already deployed open source tools into their existing ALM and PPM infrastructure will see a dramatic reduction in the predictability of their development process, since their process relies on a connectivity between development and planning tools that was present in the more traditional ALM tool stack.
There is hope. First, the benefits of open-source ALM tools are fundamental as the ease with which they allow developers to work makes us happier and more productive. The velocity of successful open-source projects demonstrates how good these tools are at supporting the delivery of high-value software that is responsive to the needs of the community and customer. On the flipside, Enterprise ALM tools provide management and planning facilities which are critical for predictability of delivery as well as the longer-term planning that is necessary for organizations to thrive. These two worlds must be integrated into a cohesive whole, especially as more Agile teams find themselves at the intersection of open source and enterprise ALM.
After I presented my keynote on open source ALM at W-JAX last November, a colleague from one of the world’s largest software companies commented that the same developers that worked on open-source projects were twice as productive as when they worked on closed source projects. We discussed the usual issues of motivation and incentive structure, but nailed down the key issue being the sheer friction generated by traditional ALM tools which has been removed from open source ALM tools. It is time to reconnect the software planning process to a new breed of open source ALM tools that support lean and high velocity delivery, connect them to the planning and management tools needed for software delivery at scale, and bring some of the benefits of open source development to the enterprise.
Watch Tasktop webinars
p
by Mik Kersten at February 08, 2011 11:59 PM
Kim Moir
Eclipsing the build
A plan item for 3.7 is to transition the Eclipse and Equinox build process to run on eclipse.org hardware.  Why may you ask, isn't this the case today? Two reasons:1.  Until recently, the Eclipse foundation didn't have hardware to support our requirements of running tests on multiple platforms (Windows, Mac, Linux).2.  There wasn't a plan item to transition our build to eclipse.org until 3.7.   You may think that we open source developers are happy hippies who have the freedom to work on the bugs that interest them :-). The reality is that I prioritize my bugs as follows:Fix bugs that cause the build to fail.Fix bugs that block other committers from moving forward with their work or are necessary for legal reasons.   Plan itemsEverything elseI was going to write a post describing the progress migrating to eclipse.org hardware but I thought it would be a good idea to give you some background regarding how the Eclipse and Equinox project's build works today.  The Eclipse build creates SDKs for 15 platforms.A graphical representation of the 15 platforms we build  (os,ws,arch)We use fragments to define platform specific code that is associated with a host bundle.  In some of these fragments, there's C code that needs to be compiled on the platform specific hardware to create binary libraries.  For instance, the SWT and equinox launcher fragments are examples of  these artifacts. We have about seven machines to compile the libraries for these 15 platforms, as some are cross compiled.  The SWT and Equinox team have hudson instances, which connect to all these internal IBM servers, compile the C code, and commit the resulting libraries in binary form to CVS at eclipse.org. This part of the build isn't transitioning to eclipse.org.A simplified description of the existing Eclipse build that produces the artifacts that are available for download on eclipse.org is shown below.   Essentially, once a build is launched from cron, the build scripts check out all the code from eclipse.org to the IBM build machine which compiles the bundles. These bundles are copied to eclipse.org to be signed, then copied back to the IBM build machine to be assembled into a p2 repo, from which we create SDKs to run the tests. The zips, repos and test results are rsynced to eclipse.org.Once we get the issues worked out with the new Hudson slaves to run tests, all the JUnit tests will run on eclipse.org hardware.  Eventually,  we hope to run the performance tests there once we have sufficient hardware.Advantages of moving the build to hudson.eclipse.orgThe build process will be more open and other Eclipse and Equinox committers will be able to start a build.  Today, I manage the crontab of the build machine.Fewer issues with network timeouts due to the fact that the eclipse.org filesystem is local to Hudson.Hudson has a rich feature set and many plugins to extend it.  DisadvantagesLike kindergarten, we'll have to share the filesystem and machines with others.  Today the build runs on dedicated machines and thus we don't have resource constraint issues from other teams.  (The build process itself isn't faster at eclipse.org because of these resource constraints, but the tests are because at the moment we are the only team using the Windows and Mac test machines.)Can't hack and slash the build on the the command line to rerun a single test suite or restart the build manually.In a future post, I'll describe the process to transition our builds to run on eclipse.org and the obstacles that we have overcome.How can you help?  Consider donating to Friends of Eclipse.  ReferencesBuild at Eclipse.orgGraphics thanks to open source clip art Servers Database iMacServer cabinet Tower Database
by Kim Moir (noreply@blogger.com) at February 08, 2011 08:07 PM
Brian Fitzpatrick
Tools, Tools, Tools... ESB, BPEL, and WS in JBoss Tools 3.2
I've seen two major releases of JBoss Tools in my year and a half at JBoss/Red Hat. In that time, the many talented folks we have working on tooling have developed new tools and updated existing ones. Functionality has been added just about anywhere you look in the tooling.  As such, I want to call out just a few of the areas we've made progress in for JBoss Tools 3.2...  First, the ESB Editor gained support for new ESB 4.9 functionality including BPELInvoke, new methods for creating ESB actions via annotations, and Camel ESB integration. And the team also added a first cut at better validation of ESB configurations to help make sure files will will work before they're deployed.  Next, there's the great BPEL Editor work that Bob has already mentioned here  Beyond that, I have to say that I'm happy with the work we've done on the Web Service Tester that's been added. I know Bob uses it for testing web services used in BPEL processes and Lukas has used it extensively in QE. More feedback would be great, but I'm happy with where we are for a first release! You can read more about the WS Tester here.  And I'm also happy with some of the new Web Service wizards we've introduced for bottom-up WS development in this release. Though the WTP Web Service wizard works, it's not the most user friendly beast in the world and it's also not the easiest framework to extend. As such, we reused a few chunks that we'd written and found ways to present a simpler approach for developing web service artifacts for existing annotated classes.  We integrate with JBossWS and JAX-WS annotated classes and we even integrate with RESTful services if you have RESTEasy installed. So hopefully these will help you get work done a bit faster than before. You can read more about these new wizards here.  So there you have a few of the areas we've worked on for this release. As always with JBoss Tools, this is just the tip of the iceberg so be sure to keep an eye out for posts celebrating functionality in other areas!
by Brian Fitzpatrick (do-not-reply@jboss.com) at February 08, 2011 05:38 PM
Bob Balfe
As a Notes developer the iPad simply rocks
I start my day by going through emails, check my schedule on the calendar, and then jump right into work. My work is spread out through Eclipse, Designer, the Composite Application editor and test is in Lotus Notes. This doesn’t set well for the project manager side of my job where I attend meetings, demo stuff, or hold my own meetings because I am constantly going in and out of Lotus Notes and launching and shutting down Lotus Notes. I would have two laptops pretty much open all of the time, one with my production Lotus Notes email, calendar, etc open and possibly even my iPhone if I was upgrading the Notes client, and another laptop to develop and test on.
Well, then came along the iPad. I now have one developer laptop open and my iPad sitting on its cover stand at the viewing angle. Bye bye second laptop! What really rocks is how fast I can get the device out of sleep mode and straight to my calendar. With Traveler synchronizing my email, contacts and calendar it all simply “works”. At Lotusphere, for the sessions I could attend, I just brought the iPad. A small notebook like device that is extremely light and easy to carry. I had heard a crazy number like 1600 iPads were brought to the Opening General Session(OGS) on Monday, wow!
I am convinced tablets are the way of the future, no more laptops! With the introduction of Orion, I will be able to do almost everything from a touch screen device. Maybe in the near future. p
by Bob Balfe at February 08, 2011 04:00 PM
Jens von Pilgrim
Extract Xtext Project Wizard
Besides a nice parser and a powerful editor, Xtext can also generate a project wizard and a generator plugin. In this little posting I will explain how to extract the project wizard related code from the generated UI plugin -- and explain why you would want to to that in the first place.First of all, what does the project wizard? The project wizard is useful to set up an initial project for your DSL, e.g., for creating initial templates, workflow files and to configure the project and its dependencies. The nice thing about the Xtext generated wizard is, that the template files are simply created using Xpand. It is very easy to provide custom templates and other stuff by simply modifying the Xpand file. You will find that Xpand template in the UI plugin, if you have enabled the wizard fragment in your DSL generator workflow:br /// project wizard (optional)br /fragment = projectWizard.SimpleProjectWizardFragment {br / generatorProjectName = "${projectName}.generator"br / modelFileExtension = file.extensionsbr /}br /This code is uncommented by default.So, Xtext generates a nice project wizard. This project wizard is found in the generated ui project. Let's say, my language is called sample.mydsl, then the wizard is created in sample.mydsl.ui, together with the powerful editor.Now, why would I want to extract this editor from the ui plugin. Actually, because I want to use the wizard during development of my language. Sounds silly... OK, here is the longer explanation:I find the wizard extremely useful especially if I have a project which uses code generation. Although you can use any kind of code generation technologies, you probably will often use Xpand and Xtend, as it is nicely integrated with Xtext. That is, Xtext can also generate a generator plugin with some template files and most notably a workflow file (MWE2).Actually, the generated generator plugin looks almost similar to a plugin project created by the generated project wizard. That is, both, the generator plugin and a project wizard created DSL project, contain a folder src/model with a sample model, and also a sample MWE2 generator file. Also, both projects contain a src-gen folder, and the plugin-dependencies are set accordingly. This is no coincidence: If you use code generation for your DSL, and if you use Xpand to perform the generation, using an MWE2 workflow to trigger the generation is a very easy solution. Alternatively, you will have to write a new action or something, but the MWE2 workflow is much easier to set up. The model provided in the generator plugin is usually only used for testing purposes. That is, you write your Xpand (and Xtend) templates in the generator plugin and you can quickly test them by applying them on the models provided in the generator model folder. Later, when the generator plugin is installed, the user of the generator won't see the Xpand templates in the workspace, however they can be accessed by the MWE2 workflow of the DSL project.During development, you probably run into the same situation as I did: You write the templates, then some things are changed in your DSL and you have do adjust the templates, or new features should be implemented, or you have forgotten some weird constellations, or you haven't written templates for all model elements. Most important: You probably will have several different models and you do not want to get the generated code to be generated in your generator plugin (as it should only define the templates, and should not contain some weird generated Java or whatever files). In my case, other guys on the project write the DSLs and I have to maintain the templates. I rarely use the generated DSL editor myself, but I often have to use the generator (and adjust the templates). Since I needed an extra project for each different case, I found myself copying the generator plugin (without the templates, but with my nicely configured MWE2 workflow) over and over again. I always had to adjust the plugin dependencies and so on. Well, a wizard would be nice in that situation. Now, you see my point? The Xtext generated project wizard is exactly what I needed -- but I need it in an Eclipse instance in which I do not have my DSL editor (and neither the DSL parser) installed, as this is the very instance I develop these things. But the wizard would come quite comfortably.So, the idea is as follows: I extracted the wizard into a separate plugin. The wizard plugin has no dependencies to my DSL, so it can be installed without my DSL plugins installed. However, the generator, i.e. the MWE2 workflow, requires all my DSL stuff. But this is no problem, as the generator plugin is an opened project in my development workspace -- thus the MWE2 workflow (not the plugin code, but the workflow) can access the project.Here is how to extract the project wizard (which is not too complicated, however it may save you some minutes):assumptionYou have an existing Xtext project, I will call it "sample.mydsl" in the following, and, of course, a generator plugin "sample.mydsl.generator" created for your DSL. Inside the generator, you have configure the MWE2 workflow.generate project wizard Enable Project Wizard Fragment in your DSL workflow, e.g. in "GenerateMyDSL.mwe2" of your DSL project:br /// project wizard (optional) br /fragment = projectWizard.SimpleProjectWizardFragment {br / generatorProjectName = "${projectName}.generator" br / modelFileExtension = file.extensionsbr /}br / Now run the workflow "GenerateMyDSL.mwe2", and disable the project wizard fragment (as we do not want to have two wizards in the end).create wizard plugin Create new plugin project (e.g., sample.mydsl.ui.wizard) with and Activator, check "This plugin-in will make contributions to the UI". Important: Use "sample.ui.wizard" as package for the Activator (without mydsl), in order to retrieve the same package names as in the Xtext generated ui project. move wizard code to new pluginMove the following classes from the generated ui plugin into the wizard -- this is the actual "extraction" of the wizard:from src-gen: sample.ui.wizard.MyDSLNewProjectWizard sample.ui.wizard.MyDSLProjectCreator from src: sample.ui.wizard.MyDSLProjectInfo sample.ui.wizard.MyDSLNewProject.xpt and copy the following classes from the generated ui plugin into the wizard plugin, put them into the wizard package: sample.ui.MyDSLUiModule from src-gen: sample.ui.MyDSLExecutableExtensionFactory Also copy the plugin from the ui plugin into the wizard plugin and remove everything except the last extension with point "org.eclipse.ui.newWizards", adjust class name of extension factory according to the class in your wizard project (you will have to add a ".wizard" to the fully qualified name). configure wizard projectIn Manifest, set singleton directive to true (if not already set) and add missing plug dependencies, e.g. br / org.eclipse.xtext.ui,br / org.eclipse.ui.editors;bundle-version="3.5.0",br / org.eclipse.ui.ide;bundle-version="3.5.0",br / org.eclipse.xtext.ui.shared,br / org.eclipse.ui,br / org.eclipse.xtext.builder,br / org.antlr.runtime,br / org.eclipse.core.runtime,br / org.eclipse.core.resources,br / org.eclipse.xtend,br / org.eclipse.xpandbr /Depending on your project, you may have to add other dependencies as well, e.g. de.itemis.xtext.typesystem if you use the great Xtext type system by Markus Völter.adjust the copied and moved java filesMyDSLUiModule is to be replaced completely: br / public class MyDSLUiModule extends AbstractGenericModule {br / br / private AbstractUIPlugin plugin;br /br /br / public MyDSLUiModule(AbstractUIPlugin plugin) {br / this.plugin = plugin;br / }br / br / public void configureLanguageName(Binder binder) {br / binder.bind(String.class).annotatedWith(Names.named(Constants.LANGUAGE_NAME)).toInstance("sample.MyDSL");br / }br / br / public void configureFileExtensions(Binder binder) {br / binder.bind(String.class).annotatedWith(Names.named(Constants.FILE_EXTENSIONS)).toInstance("MyDSL");br / }br / br / @Overridebr / public void configure(Binder binder) {br / super.configure(binder);br / binder.bind(AbstractUIPlugin.class).toInstance(plugin);br / binder.bind(IDialogSettings.class).toInstance(plugin.getDialogSettings());br / }br / br / br / // contributed by org.eclipse.xtext.ui.generator.projectWizard.SimpleProjectWizardFragmentbr / public Class lt;? extends org.eclipse.xtext.ui.wizard.IProjectCreator gt; bindIProjectCreator() {br / return MyDSLProjectCreator.class;br / }br /}br /MyDSLProjectCreator can be reused, however you may want to add some dependencies to the getRequiredBundles method, depending on the dependencies of your generated classes: br /@Overridebr /protected List lt;String gt; getRequiredBundles() {br / List lt;String gt; result = Lists.newArrayList(super.getRequiredBundles());br / result.add(DSL_GENERATOR_PROJECT_NAME);br / result.add("org.eclipse.jface.text");br / result.add("org.eclipse.jdt.core");br / result.add("org.eclipse.equinox.common");br / result.add("org.eclipse.core.runtime");br / return result;br /} br /Actually, this list is the list of required bundles of your generated code. That is, if you generate Java code which requires a plugin "my.super.plugin", you have to add the dependency here.MyDSLNewProjectWizard: you probably have to fix a problem in getProjectInfo, simply change the fully qualified name MyDSLProjectInfo to a simple name, as we have moved the info into the same package.MyDSLExecutableExtensionFactor: fix class name of plugin activator, change getInstance().getInjector("..") to getDefault().getInjector() Activator: Add initialization of Guice injector and add an injector attribute to the wizard's activator: br /public class Activator extends AbstractUIPlugin {br / ..br / Injector injector;br /br / public Injector getInjector() {br / return injector;br / }br /br / @Overridebr / public void start(BundleContext context) throws Exception {br / super.start(context);br / plugin = this;br /br / injector = Guice.createInjector(br / // Wizard:br / Modules.override(new MyDSLUiModule(this))br / // Workspace etc.:br / .with(new org.eclipse.xtext.ui.shared.SharedStateModule()));br /br / }br / ..br /}br /remove obsolte code from ui pluginremove method bindIProjectCreator in AbstractMyDSLUiModuleremove the wizard extension point definition from the ui plugin.xml, as you probably do not want to have two wizards.You can now run the wizard in the Eclipse runtime (i.e. the Eclipse started from within your initial, vanilla, installation). Of course, you can modify the Xpand template, e.g. I have simply copied and pasted the workflow of my generator plugin into that Xpand file. You may also add other adjustments as well.Now, you can export the wizard as a plugin and install it to the dropins folder of your Eclipse installation. After restarting that instance, the wizard is available in the workspace in which you develop your DSL. As it has no dependencies to the DSL, you can create new projects, which are configure as you specified above. The workflow is working, although it probably has dependencies to your DSL (e.g., it uses the generated DSL parser), at the DSL project is an opened project in your workspace.Side effect: Actually, you have extracted the Guice infrastructure as it is used by Xtext generated editors. So, even if you do not use your wizard as often as expected, you may have learned some stuff about this better-then-factory-pattern technology.
by Jens v.P. (noreply@blogger.com) at February 08, 2011 03:43 PM
Roy Ganor
Public/Private Key Encryption with Java and PHP
Lately, I was struggling with the differences between PHP and Java HMAC encryption methods. Although encryption is rarely used in my most day to day programming tasks, it can probably be useful for people who may need it in the future.In specific HMAC-SHA256 is used "for calculating a message authentication code (MAC) involving a cryptographic hash function in combination with a secret key". An interesting scenario is that a service that is hosted in a PHP Web application Server interacts with a Java client application client that consumes this service (for example Android mobile application). Since the client knows its private key it can encrypt an agreed message so the server then can verify with the given encrypted signature and authenticate the client.Enough with talking, let's see how it is done in Java vs. PHP with the following code snippets:br //**br / * Encryption of a given text using the provided secretKeybr / * br / * @param textbr / * @param secretKeybr / * @return the encoded stringbr / * @throws SignatureExceptionbr / */br /public static String hashMac(String text, String secretKey)br / throws SignatureException {br /br / try {br / Key sk = new SecretKeySpec(secretKey.getBytes(), HASH_ALGORITHM);br / Mac mac = Mac.getInstance(sk.getAlgorithm());br / mac.init(sk);br / final byte[] hmac = mac.doFinal(text.getBytes());br / return toHexString(hmac);br / } catch (NoSuchAlgorithmException e1) {br / // throw an exception or pick a different encryption methodbr / throw new SignatureException(br / "error building signature, no such algorithm in device "br / + HASH_ALGORITHM);br / } catch (InvalidKeyException e) {br / throw new SignatureException(br / "error building signature, invalid key " + HASH_ALGORITHM);br / }br /}br /where HASH_ALGORITHM is defined asbr /private static final String HASH_ALGORITHM = "HmacSHA256";br / Where in PHP, it's even simpler:br /echo hash_hmac('sha256', $message, $secretKey, false);br /
by Roy Ganor (ganoro@gmail.com) at February 08, 2011 02:52 PM
Andrew Overholt
git filter-branch help needed
The Eclipse Linux Tools project is moving from Subversion to Git. We’d like to maintain our history and I’ve used svn2git to create git repositories of our current SVN repos (see results here). I’d now like to join these repositories into one, with each sub-project’s history and contents in a sub-directory:
br /
org.eclipse.linuxtoolsbr /
|-- .gitbr /
|-- autotoolsbr /
| |-- org.eclipse.linuxtools.cdt.autotoolsbr /
| |-- ...br /
| ...br /
|-- valgrindbr /
| |-- org.eclipse.linuxtools.valgrind.uibr /
| |-- ...
I’ve tried a few methods of getting this structure including git-stitch-repo and some of the ideas at this stackoverflow post (and here).
My current hangup is trying to use the “–all” switch to filter-branch. My problem can be seen by doing the following:
br /
git clone git://github.com/overholt/Eclipse-Linux-Tools---autotools.gitbr /
cd Eclipse-Linux-Tools---autotoolsbr /
git filter-branch --index-filter 'git ls-files -s | sed "s-\t- amp;autotools/-" | GIT_INDEX_FILE=$GIT_INDEX_FILE.new git update-index --index-info amp; amp; mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD --allbr /
I get this:
Rewrite 7a6a92a4d2d1ecd018c1924877dc423790cf26b0 (1/443)mv: cannot stat `/tmp/github/Eclipse-Linux-Tools---autotools/.git-rewrite/t/../index.new': No such file or directorybr /
index filter failed: git ls-files -s | sed "s-\t- amp;autotools/-" | GIT_INDEX_FILE=$GIT_INDEX_FILE.new git update-index --index-info amp; amp; mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE
Which, according to this indicates that I have to use a different commit number. I’ve tried iterating down but this seems crazy; do I really have to guess the number? I also tried using the output of git log --pretty=format:%h | wc -l as the revision number but that doesn’t get much further.
Does anyone know what I’m doing wrong? I’d also accept other suggested methods of joining these separate git repos (and yes, I have what I believe are good reasons for doing so even though they have distinct content at the moment). Thanks! p
by Andrew Overholt at February 08, 2011 02:30 PM
Donald Smith
EclipseCon Hotel Sellout
Just a heads up / warning that the Hyatt Santa Clara has 9 rooms left for one of the nights of EclipseCon. We're obviously trying to boost the room block, but there are other events happening in Santa Clara and it's not a certainty.If you haven't booked your hotel yet, you should do so right away here.- DonPS - One of the shortest nights is the Saturday before EclipseCon because of all the European attendees who tend to arrive on Saturday afternoon. You need to act quickly as we have no pull at the hotel once things sell out.
by Donald Smith (noreply@blogger.com) at February 08, 2011 12:13 PM
Tom Seidel
Attaching information to your source-code - The Remus Eclipse IDE integration
The first Remus release as Eclipse Incubation project is approaching the final stretch. Today I want to mention a feature which is relevant for all developers that are using the Eclipse IDE.
If you use Eclipse you probably spent a lot of time with gathering information by browsing through the code, reading documentation, etc. Often you have to leave Eclipse and browse through an external system, like a Wiki, an intranet or Sharepoint.
With the Remus IDE integration you’ll be able to attach information units directly to resources in your workspace, that means to any file, folder or project. In addition Remus gives you the possibility to embed an information repository into your project  to share your attached information units with other developers. With this approach all relevant information that are required to edit the source-code you’re working on are directly linked to the piece of code. I hope you find this feature useful, if you have questions feel free to use the official communication channels to get help.
An Eclipse project with linked information units
For a detailed tutorial see the Eclipse Wiki at http://wiki.eclipse.org/Remus/IDE_Integration, there is also a screencast which shows this functionality, see http://www.youtube.com/watch?v=2xeNkAnEzEk. If you are interested, the Eclipse Foundation is hosting a webinar about the Remus project, for details, see http://live.eclipse.org/node/1005.
Remus can be downloaded via the Eclipse Marketplace, see http://marketplace.eclipse.org/content/remus-information-management/.
Whats next?
In the next posting I’ll show you how to connect Remus to your Mylyn task-list to extract data and information from your issue-tracker.
p
by Tom Seidel at February 08, 2011 09:35 AM
Jonas Helming
Test Model Generator for EMF
In several EMF projects I have seen a test model generator. The goal is to generate model instances of a certain model, which can be used for testing. For some tests, it is only important to have an arbitrary instance of a certain size, and sometimes it just makes sense to create arbitrary model instances to detect failures. We (Andrea, Metteo, Hong and Stephan) have developed a geneeirc generetor appyable for arbitrary ecore models. I am interested in feedback on this, we plan to make it available under EPL in the EMF Client Platform Project.Models can be created like this:1. Generating Ecore model (Library) without using any further Configuration:2. Generating Ecore model (Ecore ecore) using ModelGeneratorConfiguration:3. Changing values of the configuration (OCL model):
by UNICASE (noreply@blogger.com) at February 08, 2011 08:56 AM
February 07, 2011
Neil Bartlett
Using EMF in OSGi
It’s official — I ♥ EMF!
This is a surprise to me. I previously regarded modelling in general and EMF specifically as a sort of cult… obscure jargon, terrible documentation, unbearably aloof and patronising talk abstracts… but all that’s behind me now. I see the light: it’s all about the industrialisation of software, which requires both componentisation and automation. OSGi provides admirably for the first, and perhaps EMF can provide for the second.
However I wouldn’t say I’m an entirely orthodox EMFite. I’ve had to hack it about a bit, primarily to get it to work properly OSGi. At first blush using EMF in OSGi may seem trivial, after all, Eclipse is an OSGi application and EMF is designed to work in Eclipse, so EMF must work well in OSGi. Also: all cats have four legs; my dog has four legs; therefore my dog is a cat. Ahem.
EMF supports running in two distinct environments, neither of which matches my requirements. The first is in a “full-fat” Eclipse SDK or Eclipse RCP application. The second is in a traditional non-OSGi Java runtime, which the EMF docs refer to as “standalone”. However the middle ground — an OSGi environment that is not Eclipse — is not supported. That is, you cannot drop EMF into a lightweight OSGi runtime, even allowing for a few dependencies. It depends on the following eight bundles as an absolute minimum:
org.eclipse.core.runtime
org.eclipse.equinox.common
org.eclipse.core.jobs
org.eclipse.equinox.registry
org.eclipse.equinox.preferences
org.eclipse.core.contenttype
org.eclipse.equinox.app
org.eclipse.osgi
The last one is the killer: Equinox itself, meaning that EMF will run only on Equinox, not any other OSGi framework implementation such as Apache Felix or Knopflerfish.
There’s something fishy going on, though. How can EMF run in a “standalone” non-OSGi environment — with no other JARs on the classpath — but not run in Felix??
The explanation is that the EMF bundles have poor internal cohesion. In fact only the activators have a hard dependency on Eclipse classes; other parts of EMF reference them only by reflection. Since bundle activators are ignored in non-OSGi runtimes, EMF works fine there without having to put big chunks of Eclipse on the classpath. However it fails in an OSGi environment where the activator is not ignored — actually it fails during resolution, long before the activators are triggered. As far as I can tell the activators do nothing that is useful outside of Eclipse.
Hopefully the diagram clarifies the problem. We want the green bits but not the red bits; since the green is packaged into the same bundle as part of the red, we have to get all of the red.
The worst consequence is that if you use EMF to generate code for your model then your model API — even the interfaces! — will be inextricably linked to EMF and will therefore be encumbered with all those dependencies as well. As Alex discovered, the links to EMF can be minimised but not completely eliminated, and anyway to remove them would be to throw away some of the most useful functionality of EMF.
Frankly this is the kind of screw-up that makes me want to strangle Eclipse, if only it didn’t have so many necks. But can it be fixed?
If backwards compatibility were not a concern then the fix would be very simple: first, refactor the activator out into a separate bundle; then mark the dependencies optional. However, backwards compatibility is always a concern, so the EMF project is unlikely ever to do this.
The alternative is to repackage EMF into new bundles with better OSGi manifests. So that is what I’ve done, and I’m making them available so that others can enjoy the benefits of EMF without hitching themselves to the Eclipse juggernaut. Bnd makes it so simple to slice n’ dice the JARs into proper bundles. Everything’s available from my GitHub page at http://github.com/njbartlett/emf-osgi.
It’s a work in progress; the bundles available so far are as follows:
name.njbartlett.osgi.emf.minimal contains what appears to be the minimal set of packages required for any EMF-based model. This corresponds to the original org.eclipse.emf.ecore and org.eclipse.emf.common bundles.
name.njbartlett.osgi.emf.xmi contains classes for XMI marshalling/unmarshalling. It has the same content as the original org.eclipse.emf.ecore.xmi bundle.
As the bundle symbolic names are different, you’re going to be out of luck using them if you use Require-Bundle for your dependencies… but if you do use Require-Bundle then you’re not probably not interested in minimising dependencies and being portable, so you might as well use the original bundles.
Be sure not to be misled by the name “minimal” — this is still a fairly chunky bundle, weighing in at over 1Mb. That appears to be the minimum cost of using EMF, and certainly in some scenarios it is too much, but then again in many others it is a drop in the ocean. There is no free lunch, after all.
That’s it for now. I’m only at the start of my EMF journey, and I fully expect to be whacked off course a few more times. Still it seems to be a journey worth taking. p
February 07, 2011 10:30 PM
Chris Aniszczyk
EclipseCon 2011 Idol Contest
Hey guys, this year at EclipseCon 2011 we’re going to do something new, EclipseCon Idol. It’s a contest where nine EclipseCon attendees will present in Ignite Style a topic that is interesting to them. It can be about Eclipse technology, but it does not have to be. The only requirement is that humor and comedy need to be a key part of your presentation. To see a good ignite-style presentation, check out this one from The Oatmeal…
To participate in EclipseCon Idol, please contact idol11@eclipse.org for full details. There are only nine spots available. We are looking for humor, so talks like “Why Modeling is taking over the world” will not be accepted. Good examples may include “Why my cats would make great developers”, “Why authoring tech books is like working at McDonalds” and “You too can be arrogant by knowing a useless dated programming language.” I hope you enjoy it, it should definitely be entertaining after some frozen beverages!
As a reminder, it’s the last week for early registration for EclipseCon 2011 – prices go up February 14. After you register, be sure to book your hotel room right away as the hotel is filling up fast and you want to be as close to the Hyatt bar as possible. p
by Chris Aniszczyk at February 07, 2011 09:41 PM
Ian Skerrett
Goodbye to Lynn
I am sad to announce that this will be Lynn Gayowsk’s last week with the Eclipse Foundation.  Lynn has decided to accept a new position with Klocwork,  a software company here in Ottawa.
As many of you know, Lynn has been a fantastic part of the Eclipse Foundation and the Eclipse community.    She has been the organizers of the Eclipse DemoCamps, Eclipse Live webinars, Eclipse training series, Eclipse Community Awards and much more.    She is going to be missed.
Please join me in thanking Lynn for all here contributions to the Eclipse community.    Thanks Lynn!!
p
by Ian Skerrett at February 07, 2011 06:50 PM
Ankur Sharma
Self help with API Tooling Reports (Part III): Understanding the API Use Report
API Tooling reports are collection of XML files. A typical API Use Scan report will look is like thisXML│   meta.xml│   not_searched.xml│├───plugin.a.b.c (1.0.0.201101280335)│   └───com.example.myrcpproduct (1.0.0.201101280335)│       ├───API│       │       method_references.xml│       │       type_references.xml│       ││       ├───ILLEGAL_API│       │       type_references.xml│       ││       └───PRIVATE_PERMISSIBLE│               method_references.xml│               type_references.xml│├───plugin.x.y.x (1.3.0.v20100512)│   └───com.example.myrcpproduct (1.0.0.201101280335)│       ├───API│       │       method_references.xml│       │       type_references.xml...       ......XML folder is where the report is generatedmeta.xml contains the report parameters - the regex filters and locations, etcnot_searched.xml is the list of plug-in not looked into and why.The XML folder will also contain a bunch of folders whose names are plug-in id (with version) whose API are referenced (used). These folders will again have sub-folder named as the plug-id id (with version) which references those APIs. The usage (or violation) is stored  is XML files under their respective folders.This structure is very technical and for sparing you the trouble of understanding it, the report can be converted to HTML files. So it will be more useful to understand them.Example API Use HTML reportThe report has three sectionsScan Details will show the parameters used for generating the report. This information comes from meta.xml mentioned above.Additional Bundle Information gives the link to the bundles that were not searched. The color legends are self-explanatoryReferences section is a table detailing the bundles who are referenced (used) along with the number of references of different types. A reference is a usage of a type, method or field.API - any public referenceInternal - any reference from an internal packageInternal-Permissible - any reference from an internal package but visible to the consuming (or referencing) bundle due to x-friends marking in manifest.Fragment-Permissible - same as Internal-Permissible but from fragment bundlesIllegal - references which violates the API restrictions placed using JavaDoc tags.Each bundle name is a hyper-link that would open the details for than bundle. The details for org.eclipse.apitest would look like thisOpening the details shows the list of the Referenced Types (types being used). Each type can be opened (follow the hyper-link) to see each member and visibility details.This way you can find of each usage - valid or otherwise.The other API Tooling reports too are structured in similar hierarchy. However, with API Use Scans you can do more ... so stay tuned for more.
by Ankur Sharma (sharma.ankur@gmail.com) at February 07, 2011 06:32 PM
Eugene Ostroukhov
Tools Developer for Hire (Silicon Valley)
I have spent last 7 years working on Eclipse-based tools (including IDEs, visual designers, source editors) and I am looking for an opportunity to resume working in the space I am so passionate about.
I have experience of using many Eclipse frameworks including the essential Eclipse Platform (Workbench, Resources, JFace), WTP source editing, GEF, JSDT. My primary programming language is Java but I am also interested in other technologies (you can read about my project to embed Qt WebKit into Eclipse SWT on Windows and Mac that uses Qt, Cocoa and Windows APIs).
Detailed description of my skills and experience is available on my LinkedIn profile or can be downloaded in PDF or RTF format.
I can be reached on e-mail eostroukhov@gmail.com
p
by Eugene Ostroukhov at February 07, 2011 06:30 PM
Holger Staudacher
How to build a Server-Side Equinox/RAP Application
When you face the task of building a Server-Side Equinox or a RAP application (which is just a Server-Side Equinox application) you need to choose a build system from a fairly diverse palette. This choice is never easy because every build system has its pros and cons. In the end it comes down to which one you and others, love or hate.
To make this task a little easier we created a small github project called “RAP build examples”. It provides examples of how to build a RAP application with different build systems. Currently the following systems are covered:
PDE Build:
The goal of PDE Build is to facilitate the automation of plug-in build processes. Essentially, PDE Build produces Ant scripts based on development-time information provided by, for example, the plugin.xml and build.properties files. The generated Ant scripts, can fetch the relevant projects from a CVS repository, build jars, Javadoc, source zips, put everything together in a format ready to ship and send it out to a remote location (e.g., a local network or a downloads server). read more…
Tycho:
Tycho is focused on a Maven-centric, manifest-first approach to building Eclipse plug-ins, features, update sites, RCP applications and OSGi bundles. Tycho is a set of Maven plugins and extensions for building Eclipse plugins and OSGi bundles with Maven. Eclipse plugins and OSGi bundles have their own metadata for expressing dependencies, source folder locations, etc. that are normally found in a Maven POM. Tycho uses native metadata for Eclipse plugins and OSGi bundles and uses the POM to configure and drive the build. read more…
WAR Products Tooling:
The WAR Products are similar to Eclipse Products but much more lightweight. All you have to do to export a RAP application is to create a .warproduct based on a working launch configuration and press ‘export’. The exported .war file is ready to deploy. There is a function included that validates your .war file content before you’ve exported it. read more…
All the examples in the git repository follow the same pattern. They provide a simple RAP Application (the famous mail demo) and the files you need for the build. You can read the instructions on how to run each build in the README file which is provided for every example. For those of you who are not using git we’ve also created a zip file which contains the whole repository. You can download it here.
We plan to extend the examples in the future. A Buckminster example is on its way shortly. If you have experience with other systems please feel free to leave a comment and we can create an example together. p
by Holger Staudacher at February 07, 2011 05:22 PM
Florian Waibel
Poll results on RAP deployment
Thanks for participating in our survey “How do you run your RAP application today?“  The poll was online for one and a half months.  During this period we collected around 150 replies.
With positive replies from more than 60% of the respondents, war deployment is the most commonly used deployment scenario. Most are running on Tomcat/Jetty (39%). Every fourth installation of a RAP application is run on plain Equinox with embedded Jetty (26%).  Following quite far behind there are a few installations that are running RAP on a Virgo Web Server/Virgo Kernel and some home-brewed launch scripts.
At EclipseCon 2011, the Sovereign Project will present the latest on our ongoing research on clustering RAP in the talk, “Migrating Java Threads to Improve Availability of Web Applications“.
Currently we are targeting plain Equinox and Virgo Kernel installations. As a result of this poll, we’ll stretch our feelers to war deployment and the Virgo Web Server. It’s great to have your input for the project. p
by Florian Waibel at February 07, 2011 03:58 PM
Eclipse Riena
How to make an interesting presentation topic.
These days I am playing with a little project of mine, creating an iPad App for the EclipseCon conference program. So when you do that you click on a lot of talks, see their titles and description and get a good overview over the coming conference program.
And most of the talks really sound great which made me think what makes presentation proposal stand out so that they are picked by the program committee or that other people vote for them.
First I believe dont start your talk title with your own Eclipse project name. “Riena on ….” or “ECF on …” or “Virgo on….” is only interesting to people who already like your project. If you look for a new crowd, start with the problem you are solving not with the solution. So “UI Concepts for Desktop and Web using Riena” is much more compelling than “Riena for the Web”. “Building the largest Image Database in the world using EclipseLink” is better than “EclipseLink also stores images”.
Second try an usual title. The one I tested a lot on my iPad App is this “INTERSTELLAR THERMONUCLEAR WAR … with ECF – Multiplayer Game Development for High-Latency Mobile Networks“. I really like the title and as far as I know, it is the longest title in the conference program. (so that is good for testing an iPad App)
I am intrigued to create a talk myself like “Creating a Interstellar Thermonuclear controller center using Riena UI’s pattern” but I am not stealing ideas. I am serious, I think the above title is a compelling combination of a project (ECF) and a fun and nerdy topic like a game.
And there are many other good talk topics in the EclipseCon program that put in the problem area in the front of their title and promise to be entertaining and interesting. (i.e. “Have your Cake and Eat it Too: Embedding Web UIs in your Eclipse application.“)
Third its also helpful to do a brainstorming in your team and get many views from others. We did just that after the EclipseCon program was choosen and had new ideas for presentation titles like these:
- De-Spaghetti Your UI
- Tired of Spaghetti UI
- The Missing SWT Widgets
and many more….. (which I keep to myself for the moment)
So be creative, it helps you get your message over and its keeps it interesting for the people listing.
And here some little screenshots from the iPad app in case you are curious.
p
by Christian Campo at February 07, 2011 03:40 PM
Chris Aniszczyk
Eclipse Indigo IP Deadline
The deadline to get your eclipse.org Contribution Questionnaires (CQ) in for the Eclipse Indigo release is Feburary 11th.
This means that any third party packages that you would like to include in the release train, you need a CQ. Indicate that you need it for Indigo on the CQ and the IP Team will make sure it’s appropriately prioritized. This year’s big Indigo release review will be run from June 1-8, 2011. The IP team will need the review documentation prior to June 1, 2011 and IP logs by May 18, 2011.
Other than that, I’m looking forward to this year’s release train! I’m also looking forward to help naming the next release train… there are so many good options that start with the letter ‘J’ p
by Chris Aniszczyk at February 07, 2011 03:25 PM
Eclipse Announcements
EclipseCon Early Registration Deadline is February 14: Register Today!
The early deadline for EclipseCon 2011 registration is February 14. After this date, the registration price will increase by $250. Check out the entire EclipseCon
program at www.eclipsecon.org/program p
February 07, 2011 02:02 PM
Stephane Begaudeau
Acceleo at the Topcased Days 2011
Last Friday, I was at Toulouse for the first edition of the Topcased Days. During this conference, I had the opportunity to realize a presentation of Acceleo 3. This was a huge success and this was a great occasion to meet lots of Acceleo users. I had a great time seeing presentations from Acceleo users and watching how they are using Acceleo to generate code for satellites, planes etc. The organization was great and it was both very friendly and professional. I will put the videos of my presentation online soon for those who couldn’t be there and you’ll be able to find a link to this presentation on the Acceleo wiki.
Speaking of the Acceleo wiki, as Cédric mentioned before, it is making a fresh start with more content and an improved navigation. Now the wiki will take a main place in the Acceleo community, and you will find in one place everything needed to use Acceleo.
You will also be able to find a table of the features available in Acceleo 3 and the new things that we will work on for the next release, including a wishlist for those who want to contribute to Acceleo. Some of those subjects may be used for the upcoming Google Summer of Code. This wiki will be updated with links to videos, tutorials, and community content. p
February 07, 2011 11:54 AM
Tom Schindl
Enhanced RCP: How views can communicate – The e4 way
Some weeks ago I published how views can communicate using the EventAdmin-Service. To get things working in an 3.x application one has to write some glue code but more importantly one has to know about all those nifty things about event publishing, getting access to OSGi-Services, … .
One of the main topics of the Eclipse 4 Application Platform was to make easy things easy by removing the need to know about all the concepts by hiding them using DI. The service responsible to deliver events in application built on top the Eclipse 4 Application Platform is the EventBroker-Service:
package org.eclipse.e4.core.services.events;
public interface IEventBroker {
public String DATA = "org.eclipse.e4.data"; //$NON-NLS-1$
public boolean send(String topic, Object data);
public boolean post(String topic, Object data);
public boolean subscribe(String topic, EventHandler eventHandler);
public boolean subscribe(String topic, String filter, EventHandler eventHandler,
boolean headless);
public boolean unsubscribe(EventHandler eventHandler);
}
This is all we need to know (assuming we have already understood how DI-works) to implement our sender and receiver views:
public class SenderView {
@Inject
private IEventBroker eventBroker;
private Button b;
@PostConstruct
void init(Composte parent) {
parent.setLayout(new GridLayout());
b = new Button(parent, SWT.PUSH);
b.setText("Send Event");
b.addSelectionListener(new SelectionAdapter() {
@Override
public void widgetSelected(SelectionEvent e) {
Date d = new Date();
eventBroker.send("viewcommunication/syncEvent",d);
eventBroker.post("viewcommunication/asyncEvent", d);
}
});
}
@Focus
void focus() {
b.setFocus();
}
}
These are some fewer lines of code which is good but IMHO the more important fact is that you are independent from OSGi running now so the code you have there is much easier testable by simply mocking IEventBroker!
Let’s look now at the receiver side of the story. If you take a look at the IEventBroker you see the subscribe methods which allows us to subscribe to various topics so we could as a first step implement it like this:
public class ReceiverView {
@Inject
private IEventBroker eventBroker;
private TableViewer viewer;
@PostConstruct
public void init(final Composite parent) {
parent.setLayout(new FillLayout());
viewer = new TableViewer(parent);
viewer.getTable().setHeaderVisible(true);
viewer.getTable().setLinesVisible(true);
viewer.setLabelProvider(new ColumnLabelProvider() {
@Override
public String getText(Object element) {
return DateFormat.getDateTimeInstance().format(element);
}
});
EventHandler handler = new EventHandler() {
public void handleEvent(final Event event) {
if( parent.getDisplay().getThread() == Thread.currentThread() ) {
viewer.add(event.getProperty(IEventBroker.DATA));
} else {
parent.getDisplay().syncExec(new Runnable() {
public void run() {
viewer.add(event.getProperty(IEventBroker.DATA));
}
});
}
}
};
eventBroker.subscribe("viewcommunication/*",handler);
}
@Focus
void focus() {
viewer.getTable().setFocus();
}
}
This is once more making your code looser coupled because you are independent from OSGi running but we can do even better by fully leveraging the Eclipse DI-Framework. By default Eclipse DI injects data it has stored in its IEclipseContext (you can think of the IEclipseContext as a Map where the value is thing that gets injected into you “POJO”).
The important thing for us is that one can extend Eclipse DI to consult other resources like e.g. Preferences (@Preference) and e.g. Event-Data (@EventTopic) – a blog post explaining how this works will follow hopefully soon.
So we can rewrite our receiver code like this:
public class ReceiverView {
private TableViewer viewer;
@PostConstruct
public void init(final Composite parent) {
parent.setLayout(new FillLayout());
viewer = new TableViewer(parent);
viewer.getTable().setHeaderVisible(true);
viewer.getTable().setLinesVisible(true);
viewer.setLabelProvider(new ColumnLabelProvider() {
@Override
public String getText(Object element) {
return DateFormat.getDateTimeInstance().format(element);
}
});
}
@Inject
void eventReceived(@EventTopic("viewcommunication/*") Date date) {
Display d = viewer.getControl().getDisplay();
if( d.getThread() == Thread.currentThread() ) {
viewer.add(date);
} else {
parent.getDisplay().syncExec(new Runnable() {
public void run() {
viewer.add(date);
}
});
}
}
@Focus
void focus() {
viewer.getTable().setFocus();
}
}
[Update 2011-02-07] – Start
But we can do even better so that we don’t need to take of the UI-Thread syncing all we need to do is use another annotation:
@Inject
void eventReceived(@UIEventTopic("viewcommunication/*") Date date) {
viewer.add(date);
}
Now the DI-Framework takes care of the Event loop syncing. Thanks to Brian de Alwis for pointing this out.
[Update 2011-02-07] – End
If you are interested in how you can use things like this in your Eclipse 3.x applications and you are going to be at EclipseCon you should come to my talk about “Singlesourcing for Eclipse 4.x and Eclipse 3.x”
p
by Tom Schindl at February 07, 2011 10:40 AM
Manuel Selva
How drop GEF editors figures in the outside world
In a Gef editor I want to let the users drag and drop figures (== model objects) to an other custom view available in my tool’s perspective.
Adding a DragSource with my own drag transfer on my GEF editor figure canvas allows that. But as a side effect, and I don’t want this side effect, this disable the possibility to move the figures INSIDE the editor using drag and drop.
After investigations I found this post on eclipse forums. The solution is acceptable but not perfect. Thus I investigated deeper and came to the following pure SWT snippet that explains why we have this behavior: MouseMove events (the ones used by gef to support dragging INSIDE the editor) are no more fired once a drag source has been added:
import org.eclipse.swt.dnd.DND;
import org.eclipse.swt.dnd.DragSource;
import org.eclipse.swt.dnd.DragSourceEvent;
import org.eclipse.swt.dnd.DragSourceListener;
import org.eclipse.swt.dnd.FileTransfer;
import org.eclipse.swt.dnd.Transfer;
import org.eclipse.swt.events.MouseEvent;
import org.eclipse.swt.events.MouseListener;
import org.eclipse.swt.events.MouseMoveListener;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;
public class SwtTest {
public static void main(String[] args) {
final Display display = new Display();
final Shell shell = new Shell(display);
shell.addMouseMoveListener(new MouseMoveListener() {
@Override
public void mouseMove(MouseEvent e) {
System.out.println("Mouse move");
}
});
DragSourceListener dragListener = new DragSourceListener() {
public void dragFinished(DragSourceEvent event) {
System.out.println("dragFinished");
}
public void dragSetData(DragSourceEvent event) {
System.out.println("dragSetData");
}
public void dragStart(DragSourceEvent event) {
System.out.println("dragStart");
}
};
DragSource dragSource = new DragSource(shell, DND.DROP_COPY | DND.DROP_MOVE);
dragSource.addDragListener(dragListener);
dragSource.setTransfer(new Transfer[] { FileTransfer.getInstance() });
shell.pack();
shell.open();
while (!shell.isDisposed()) {
if (!display.readAndDispatch())
display.sleep();
}
display.dispose();
}
}
I guess this is the normal behavior fro man SWT point of view.
As a side note I would be interested for a solution to this issue other that the one proposed on Eclipse forum consisting in activating my DragSource only if a given condition is met such as Shift is pressed (this is done in a DragSourceListener.dragStart method by setting event.doit to false.
p
by Manuel at February 07, 2011 09:27 AM
Simon Zambrovski
Validating JFace Databinding with JSR-303
JFace Databinding enables an easy binding between values inside of data models and SWT/JFace widgets. No more boring listeners to implement – just create observables and connect them using the data binding context. There are several brilliant articles written about it. My favorites are those from
Ralf Ebert and
Lars Vogel.
One of the interesting aspects of databinding is data validation. The update strategies, responsible for propagation of changes in models or in widgets can be supplied with validators, making sure that the data changes are legal. In the same time the
JSR-303 Bean Validation specification focuses on a modern standardized way of data validation. In this post, I combine these subjects and use JSR-303 in JFace Databinding Validators.
One of the core insights of the JSR-303 is the idea of annotation of data validation constraints on data itself. It is indeed a good observation, that validation code strongly relies on the data structure and semantics. To follow this idea consequently, the application developer should care of validation during implementation of business logic as less as possible. A much better idea is to encapsulate the entire validation into domain-specific types. Let me demonstrate it by example, imagine the following class:
public class Customer {
private String name;
private String address;
private String zip;
private String city;
}
This is perfectly reasonable, but now consider not only the data storage/transport aspects, but also the validation aspects. A standard approach would be to use the following validator logic, in the databinding:
public class CustomerComposite {
[...]
public void bindValues(Customer model, DataBindingContext dbc) {
UpdateValueStrategy m2t = new UpdateValueStrategy();
m2t.setAfterGetValidator(new IValidator() {
@Override
public IStatus validate(Object value) {
String name = (String) value;
if (name == null || Helper.isRegex(name, "[A-Za-z -]*")) {
return ValidationStatus.error("Wrong name");
}
return ValidationStatus.ok();
}
});
dbc.bindValue(WidgetProperties.text(SWT.Modify).observe(namefield),
BeanProperties.value(Customer.class, "name").observe(model),
new UpdateValueStrategy(), m2t);
m2t = new UpdateValueStrategy();
m2t.setAfterGetValidator(new IValidator() {
@Override
public IStatus validate(Object value) {
String zipCode = (String) value;
if (zipCode == null || zipCode.length() gt; 5 || zipCode.length() lt; 5 || Helper.isRegex(zipCode, "[0-9]*")) {
return ValidationStatus.error("Wrong zip code");
}
return ValidationStatus.ok();
}
});
dbc.bindValue(WidgetProperties.text(SWT.Modify).observe(zipfield),
BeanProperties.value(Customer.class, "zip").observe(model),
new UpdateValueStrategy(), m2t);
[...]
}
Pretty much code, and rememeber that JFace Databinding code like this can not be reused in other parts of the application. Let’s put the validation logic on the data declaration in a way how JSR-303 proposes to do this:
public class Customer {
@NotNull
@Pattern(regexp = "[A-Za-z -]*")
private String name;
private String addressLine;
@Size(min=1, max=5)
@Pattern(regexp = "[0-9]*")
private String zip;
@NotNull
@Pattern(regexp = "[A-Za-z -]*")
private String city;
}
As a next step, let us develop an update strategy factory which create update strategies with embedded Validator for JSR-303 Bean Validation constaints.
public class BeanValidator implements IValidator {
private ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
@Override
public IStatus validate(Object value) {
Set lt;ConstraintViolation lt;Object gt; gt; violations = factory.getValidator().validate(value,
new Class lt;? gt;[] { Default.class });
if (violations.size() gt; 0) {
List lt;IStatus gt; statusList = new ArrayList lt;IStatus gt;();
for (ConstraintViolation lt;Object gt; cv : violations) {
statusList.add(ValidationStatus.error(cv.getMessage()));
}
return new MultiStatus(Activator.PLUGIN_ID, IStatus.ERROR,
statusList.toArray(new IStatus[statusList.size()]), "Validation errors", null);
}
return ValidationStatus.ok();
}
}
public class StrategyFactory {
public static UpdateValueStrategy getStrategy() {
UpdateValueStrategy strategy = new UpdateValueStrategy();
strategy.setAfterConvertValidator(new BeanValidator());
return strategy;
}
}
Using the StrategyFactory, the validation code inside of the composite becomes trivial:
public class CustomerComposite {
[...]
public void bindValues(Customer model, DataBindingContext dbc) {
dbc.bindValue(WidgetProperties.text(SWT.Modify).observe(namefield),
BeanProperties.value(Customer.class, "name").observe(model),
new UpdateValueStrategy(), StrategyFactory.getStrategy());
dbc.bindValue(WidgetProperties.text(SWT.Modify).observe(zipfield),
BeanProperties.value(Customer.class, "zip").observe(model),
new UpdateValueStrategy(), StrategyFactory.getStrategy());
[...]
}
An important property of the introduced validation approach is the fact, that it can be reused in other application layers (e.G. in service layer, or in data access layer). In other words you can use the same validation logic across the entire application and just remain valid… p
by Simon Zambrovski at February 07, 2011 09:22 AM
Deepak Azad
JDT 3.7 M5 - New and Noteworthy
This time there are a bunch of interesting items in the debug areaThere is now a history for recently used breakpoint conditions:The global history shows the saved conditions across all conditional breakpoints, while the local history shows the history of one particular breakpoint.In the Java editor, if you delete a breakpoint that has a condition set on it, you will now be prompted before the breakpoint gets deleted:You can specify that you would not like to be notified again when trying to remove a conditional breakpoint. This can later be changed again via Prompt for confirmation when deleting a conditional breakpoint from editor on the Java gt; Debug preference page.If you accidentally removed a breakpoint from the editor's vertical ruler or the Breakpoints view, you can now get it back using the standard undo functionality - Edit gt; Undo Delete Breakpoint (Ctrl+Z) - in the Breakpoints view or any other view that works against the global undo history.The Add missing case statements quick assist is now available in the body of the switch statement:The Quick Outline shows inherited members of top-level types when Ctrl+O is pressed twice. Now, it also shows inherited members of the type that contains the current editor selection:The focus types that can show inherited members are marked with a triangle.Two new compiler options have been added that mark methods which can be made static because they only refer to static members.The first option marks private and final methods than can always be made static. The second option also marks other methods. Note that methods can be overridden in a subclass, so if you make a "potentially static" method static, this may break existing clients. These options are disabled by default.Another interesting feature in the SDK is detached editors. This can be really useful in a dual monitor setup.  Though while trying this out I 'lost' a couple of editors before filing Bug 336391
by Deepak Azad (noreply@blogger.com) at February 07, 2011 03:59 AM
Rafael Chaves
Model-driven Development with Executable UML models
Last November I did a lecture on Model-driven Development with Executable UML models to a class of Software Engineering undergrad students at UVic. Here are the slides:
I think it gives a good summary of my views on model driven development (with Executable UML or not):
even though problem domains are typically not very complex, enterprise software is complex due to the abundance of secondary crosscutting concerns (persistence, concurrency, security, transactions etc)
there are two dominant dimensions in enterprise software: business domain concerns and technological concerns
they are completely different in nature (change rate, abstraction level) and require different approaches (tools, skills, reuse)
MDD is a strategy that handles well that divide: models address business domain concerns, PIM- gt;PSM transformation addresses technological concerns
brainstorming, communication, documentation and understanding (rev. engineering) are not primary goals of MDD – to produce running code in a productive and rational way is
models in MDD must be well-formed, precise, complete, executable, technology independent
graphical representations are not suitable for executable modeling (textual notations are much better)
diagrams != models, text != code (that would look good on a t-shirt!)
I guess those who know me won’t have seen anything new above (these ideas make the very foundations of the TextUML Toolkit and AlphaSimple).
Do you agree with those positions? p
by rafael.chaves at February 07, 2011 01:52 AM
February 06, 2011
Fabian Steeg
Setting up Contracts for Java in Eclipse
On Friday, Contracts for Java was announced on the Google Open Source Blog. Learning about this at the beginning of the weekend was perfect timing for me: I had time to check it out, and while setting it up was some work, I was hooked right away.
Now something like Contracts for Java is only really useful if it is well integrated into the tools you use everyday – which in my case is Eclipse. Eclipse allows many levels of integration, and I quickly had it working by running javac as an external tool – which is OK, but not ideal, since it requires running the tool manually after every change to the annotations, and doesn’t give in-place error messages. I quickly found out Eclipse has support for custom annotation processing. I had to fiddle a little until I got that configured properly with Contracts for Java so I thought I do a quick write-up so other people can try this cool new tool in Eclipse.
Contracts for Java doesn’t provide any binary downloads yet, so my first step was to build a Jar. To use it, create a Java project, and add cofoja-latest.jar and asm-all-3.3.1.jar to the build path. Then add some code that uses contract annotations (copy and paste the code below into the src folder of the project):
import com.google.java.contract.Ensures;
import com.google.java.contract.Requires;
public class Contracts {
public static void main(String[] args) {
System.out.println(new Numbers().add(-10, 5));
}
}
class Numbers {
@Requires({ "c gt; 0", "b gt; 0" })
@Ensures({ "result gt; a", "result gt; b" })
int add(int a, int b) {
return a - b;
}
}
Next, configure the annotation processing in the project properties gt; Java Compiler gt; Annotation Processing. To make Contracts for Java work with the Eclipse Java compiler, currently some specific properties have to be set up: set the com.google.java.contract.classpath property to the absolute path of your cofoja-latest.jar (you can find the path by checking the file properties) and set the com.google.java.contract.classoutput property to the absolute path of your project’s src folder:
Make sure you have set up your workspace to refresh automatically in Preferences gt; General gt; Workspace to make Eclipse see the resources generated by the annotation processor. Then, add the cofoja-latest.jar to the project properties gt; Java Compiler gt; Annotation Processing gt; Factory Path:
Now issues in the annotation values are reported in the editor, like variables that cannot be found, e.g. for our code above:
To have the contracts checked at runtime, add -javaagent:cofoja-current.jar to the VM arguments of your run configuration:
Now when running, we are made aware of the violated precondition in our code:
After we fix the call violating the precondition to new Numbers().add(10, 5); we now see our implementation of add does not fulfill the postcondition:
After fixing our implementation to return a + b; the code now runs without errors. For further information on using Contracts for Java check out the project wiki. General information on design by contract can be found elsewhere.
p
by Fabian Steeg at February 06, 2011 11:12 PM
Robert Konigsberg
@RunAsJUnitTest, @RunAsPluginTest
After many idle months I'm starting to pick up work on the Workspace Mechanic for Eclipse, and that included finally publishing some of the tests that accompanied it.And then, after starting to work on the tests some more, I realized I was missing something I used while writing plug-ins internally at Google, and so I copied them into the internal tests package. They're mostly documentation, but useful documentation. Here's the slightly reduced code for both of them. Their purpose should be clear:/**br / * Declares that this test can be run as a JUnit test, and does not requirebr / * the trappings of running as an Eclipse plug-in test.br / */br /@Retention(RetentionPolicy.RUNTIME)br /@Target({ElementType.TYPE, ElementType.METHOD})br /public @interface RunAsJUnitTest {br /} /** * Declares that this test must be run as a plug-in test. */@Retention(RetentionPolicy.RUNTIME)@Target({ElementType.TYPE, ElementType.METHOD})public @interface RunAsPluginTest {}Nobody likes running tests in the plug-in container if he or she doesn't have to. Surely, I'd much rather run nice fast JUnit tests, particularly when I've separated out code specifically for fast unit tests.Of course, without infrastructure to support these, they're little more than documentation, but documentation that has type completion in the IDE.So, what do you think? Would it be reasonable to have Eclipse support annotations like these? Do you think these have merit, or are utterly worthless?
by Robert Konigsberg (noreply@blogger.com) at February 06, 2011 07:51 PM
February 05, 2011
Webtools News
WTP 3.3 M5 Declared!
The fifth development milestone for WTP 3.3 has been declared. Check out what's
New and Noteworthy
and
download
it now! It's also an excellent time to test the Indigo development packages and see how this year's Simultaneous Release is progressing.
More news p
February 05, 2011 08:00 PM
February 04, 2011
Ankur Sharma
Self help with API Tooling Reports (Part II): Generating the API Use report using Ant Task
The API Use report can also be generated using Ant tasks. See Eclipse help documentation for it here. If you already know how to run ant tasks in Eclipse, skip the rest of it.1. Writing Ant scriptI assume you know a bit of Ant already. If not, stop and step over to Ant Tutorial.Create a new File and lets call it GenerateApiUseReport.xml. It will open in default text editor. Close it and Open it with Ant Editor (use right click on file and select 'Open With' - gt; 'Other...')Now write this in the file.The parameters match to the UI we discussed before.Ant Parameters                UIlocation                       lt;= gt; Analyzescopepattern               lt;= gt; Bundles matchingreferencepattern       lt;= gt; References toreport                           lt;= gt; Report Output Locationconsiderinternal       lt;= gt; Internal referencesconsiderapi                 lt;= gt; API referencesconsiderillegaluse     lt;= gt; Illegal API UseThese two are not in UIarchivepatterns - Its exclude filter. It will be a comma-separated list with the format lt;bundle-id gt;: lt;relative-path-to-jar gt;debug - Supplying a "true" will make the apitooling.apiuse ant task give out all the debug trace information. This might be helpful if for some reason the results are not expected and you need to investigate. Since default value is false, I would recommend leaving it out until you need it and know what you are doing.2. Running the scriptThis is simple. You have to create a new Ant Build launch config from the External Tools Configuration wizard. But why do it when there is a shortcut. Just right-click in the ant editor and select 'Run As' - gt; '2. ant Build...'. This will automatically create an Ant Build launch config for you and open it. It will look like thisHit the Run to execute the script. You can open this again from External Tools configuration wizard.3. Generating HTML reportsThe apitooling.apiuse ant task only generating the XML report. For generating the HTML reports we need to invoke the apitooling.apiuse_reportconversion task. The parameters are very simple. See the documentation here.Since we would want to do this along with the report generation only. We can add this to same Ant script andmake it look like thisbr / br / br / br / br /br /
by Ankur Sharma (sharma.ankur@gmail.com) at February 04, 2011 05:10 PM
Chris Aniszczyk
EclipseCon 2011 Mobile Apps
We’ll have mobile applications available for people during the EclipseCon 2011 conference this year thanks to the awesome folks at itemis mobile.
I’ve been doing some beta testing recently and things are going well.
My question to all y’all is what type of features would you like to see in the final application? I was thinking of adding some social media aspects to the application involving tweeting the talks you’re about to attend amongst other things. It would also be nice to vote-in-application for sessions you’ve attended, but in the end, we can only do so much to improve the application.
What do you think? p
by Chris Aniszczyk at February 04, 2011 04:19 PM
Denis Roy
Eclipse makes refactoring fun.
"Well, duh" you say.For seasoned developers and code gurus, you already know that. But for server guys like myself, the thought of a major refactoring of code -- especially code not authored by self -- leads to nightmares.I spent the last few days getting intimate with Eclipse Helios and the PDT working on bug 303756. To my own surprise, I am progressing remarkably well thanks to Eclipse's navigation tools, content assist, and the little things like CTRL+SPACE.
by Denis Roy (noreply@blogger.com) at February 04, 2011 02:51 PM
Andreas Hoegger
SQL formatter for Eclipse Scout 3
We finally integrated our own SQL formatter into Eclipse Scout 3 which leads to smoother LOG output and to much more easy analyzing of low level query issues.
You might know that feature from Scout 2 already. You can find that code in the package org.eclipse.scout.rt.server.services.common.jdbc.parsers.sql. It is an atomic package and can be copy/pasted into older eclipse scout projects as well.
You may see some rare statements which are not perfectly formatted. Please send them to the Eclipse Scout forum or as a bugzilla. Nevertheless, we are permanently working on enhancing this feature.
Here is a cool example…
p
by aho at February 04, 2011 09:01 AM
Ekkehard Gentz
OOP2011, entwicklerTAGE2011, EclipseCon2011, JAX2011
sometimes I have the feeling it’s always conference season
one week ago I had much fun to present a workshop at (german) OOP 2011 about ‘Business UI modeldriven‘. this was a real challenge for a one-day-only workshop:
I gave an overview about development of Business UI for enterprise apps
jonas explained EMF. most from audience never used EMF before – so this was different to sessions at eclipse conferences
flo talked about the architecture of redView
max demonstrated how to use the  EMFStore
and the 2nd part of the day I did live hacking code:
developing a RCP app using Riena Toolbox
creating a business UI with redView from scratch
generating a prototype of business UI from EMF domain model to (redView) views with tabfolders, mockup data and more using red-open (Xpand/Xtend, MWE)
next 2 weeks or so we’ll publish this workshop (250 slides have to be translated in english) and we’ll add some videos so everyone can try it out. of course there will also be the example projects available together with the solutions so you can compare if you did all lessons well.
end of february I’ll have a 2-day workshop about ‘Enterprise goes mobile: Push Services to mobile devices’ covering BlackBerry and Android where I’ll also present my Equinox OSGI Server as the heart of the communication-lifecycle. …will report about this solution later…
march is always the month with my favorite conference: the eclipseCON where I’ll present all news from redView project: Dynamic Views for Business Apps.
but much more important is to meet you all face-to-face.
I’m also working on a BlackBerry Conference App for EclipseCON 2011 - stay tuned… development will start soon
in may I’m speaking at the (german) jax 2011 conference.
last year I moderated the Enterprise Eclipse Day – this year I have the pleasure to be part of two Eclipse Days moderated by Lars Vogel and Kai Tödter.
Enterprise to go – mobile business apps and Eclipse RT – as part of the Eclipse Runtime day moderated by Kai Tödter
EGit/JGit and Mercurial: DVCS at Eclipse – as part of the Eclipse Tools day moderated by Lars Vogel
in june will follow the Eclipse Democamps celebrating the Indigo Release
unfortunately between all these great events there must be done some work on customer projects
see you all at EclipseCON – and if you’re in the region of Munich:
Eclipse Stammtisch 2011-02-22 in Munich
where: Unions Bräu
when: 7pm
organized by Max and Jonas from EMFStore and me
please register here to help us organizing the evening
…you can meet me at the longest Eclipse Stammtisch ever
Unions Bräu is a great brewery … Ralph Müller will also be there
————————————————————————————————————————–
Filed under: Blackberry, Eclipse, EclipseCon, EMFStore, redview, Riena p
by ekkescorner at February 04, 2011 07:50 AM
Eclipse Labs - Most Active Project
Eclipse Labs Projects Update for the week of February 3rd 2011
Most Active Projects
code-recommenders - IDE 2.0: Bringing Collective Intelligence into Software Development
anyedittools - AnyEdit plugin adds several new tools to the context menu of text based Eclipse editors, to Eclipse main menu and editor toolbar
birt-controls-lib - A collection of BIRT ReportItems created through the ReportItem extension point.
birt-functions-lib - A collection of BIRT Aggregate and Script Function Extensions for use in your project
android - android
wascana - Wascana Eclipse C/C++ IDE for Windows Developers
ostool - Central metadata repository for unstructured data supports records and knowledge management for small and medium-sized organisations.
e-dziennik-inz - Elektroniczny dziennik wspomagania prowadzenia zajęc
muathuoc - muathuoc
onotoa - Onotoa is a visual editor for the Topic Maps Constraint Language.
February 04, 2011 04:59 AM
Vineet Sinha
Making Cool Ideas Happen: Studying Our Users and Software Immigrants
One of the nice things about being Software Developers, is that it’s really nice to spend our time working on cool ideas:  building out systems that help in situations where no solution currently exists. The problem is that often these cool ideas fail. Yes, using an Agile approach helps significantly, especially when customers/users request features. [...]
by Vineet Sinha at February 04, 2011 03:13 AM
Mik Kersten
Prediction #6: Continuous integration becomes central to deployment, Jenkins attacks Hudson with a chicken
How does a continuous integration (CI) tool named after a butler or two grab such a large market share when much more feature-rich and polished commercial counterparts exist? The naïve answer is that it’s free. If you dig a bit deeper, the success of Hudson can be seen as part of a larger trend in developer-centric application lifecycle tools. A growing number of open source tools have hit the mark in capturing developer collaboration and Agile lifecycle management practices. What has caused these tools to snowball in popularity is the rich ecosystems of extensions that they support. That combination has become lucrative to larger organizations wishing to increase the productivity of their developers. When an open source community starts smelling of money-making potential, a different breed of dog moves in. This can be a very good thing, as it is often the catalyst needed to move the project across the chasm to broad industry adoption.
The challenge for popular open source projects is to create a governance model that marries the interests of the project’s community with those of vendors supporting the project. The most successful open source projects are ones that manage this dichotomy without alienating either party. Spring, JBoss and MySQL won by having a single dedicated vendor managing commercial and community interests. Eclipse and Apache have created governance models that support the overlapping interests of multiple vendors. In the case of Hudson, with Kohsuke’s departure from Oracle, a split formed. In recent blog posts we’ve seen Kohsuke Kawaguchi, creator of Hudson, highlighting the community and the ecosystem of extensions that have made Hudson successful to date. On the public forums, Oracle’s Ted Farrell has emphasized the importance of versioning, consistency and stability, which are relevant for taking Hudson to the next level of enterprise adoption. Both of these concerns need to be addressed.
Over the coming year, extensible continuous integration is going to play a key role in both on-premise ALM stack modernizations and cloud-hosted ALM solutions. If you have a few grey hairs on your head, this may not sound new or noteworthy. A decade ago, we set up a CI build for AspectJ.org with CruiseControl and Ant and it is still running today. More modern Mylyn CI builds are very similar, but running Hudson and Tycho. What’s interesting is that over the past decade the continuous integration loop has become the underpinning of build automation in the Agile development process. Easy extensibility has made CI servers a convenient hub for plugging a variety of ALM tools into the Agile build loop. We are moving away from a world where realses, code metrics, testing tools and deployment destinations are being configured by each developer within his or her IDE. Instead, the CI server is becoming the hub that holds the authoritative build specs, with developers attaching to the portion of the ALM artefacts that they need to work on for the current release. Testing, quality, and metrics tools will increasingly use the CI server as the place to hook into the development process. In an upcoming prediction, I’ll discuss how combining task-focused workflow with continuous integration will prove to be a convenient abstraction for tool support that facilitates knowledge capture and sharing between Planning, Dev, Ops and QA.
All of this potential means that Hudson is a hot topic, and that Hudson’s consumers are scratching their heads on what to do about the Jenkins fork. Hudson’s success to date comes from the typical mix of passionate community leadership, open source extensibility and a vendor-sponsored marketing investment that helped create that community. The latter is often omitted from developers’ discussions, but now that we are in the later stages of open source maturity, a project’s access to marketing resources has become a key component to success. A case in point is the significant marketing budget of successful open source foundations, or that of the Mozilla Foundation’s, which is in the millions.
In open source, community-centric passions drive projects to their initial critical. Then comes the point at which enterprise support, stability, and the ability for other vendors to invest in a project become relevant. These help a project to graduate from an early adopter community to the pragmatists who can establish an open source project as a de facto standard. For that to happen, a project must be bigger than the cult of personality around its founder, just as any organization must be bigger than its leader to thrive. But with the heart of the contributor community in his hands, and his brain more wired to the technical vision of the project than any other person’s on the planet, the founder is often required to drive major downstream innovations.
In the year ahead, the existing consumers of Hudson will vote with their feet whether to go with the forked Jenkins codebase or with Hudson. The question will largely boil down to how stable the core of Hudson is, and whether upcoming changes to the core of Hudson that happen within Jenkins, and its key extensions, warrant a migration. In the closer-knit community there will be a tendency to Jenkins, as represented two hundred community votes, the majority of which were in favour of the fork. But in the much larger end-user community the default will be resistance to change in the absence of major and clear value add to making the move. We’ve seen this on Eclipse with the overly slow migration of many plug-ins to e4, which brings incremental value add and only benefit.
The large and more conservative consumers of Hudson will look to which corporate sponsor, Oracle for Hudson and the CloudBees startup for Jenkins, is providing better long-term assurance for their build infrastructure investment. There will be questions about Jenkins’ promise of neutrality. In the past, genuine open source project neutrality has only been achieved by large open source foundations with sufficiently diverse funding sources, and even then with mixed success. As such, while Jenkins is likely to see activity, Oracle’s Hudson is unlikely to go away and I predict that it will continue to be a major target of CI deployments through the year.
In the interim, as with the Emacs vs. XEmacs fork of the 90s, there will be some confusion and annoyance from those less interested in the drama. Thankfully John Ferguson Smart wrote his Continuous Integration with Hudson book in open source fashion, making it easier to refactor. If the divergence between the two projects is sufficient to fragment and fracture the community, there could be a large enough gap for a new open source CI system to join the scene, but it would take time for it to build up momentum. In the meantime, the usual API-level federation layer is likely to form so that plug-ins can support both tools, and we’re invariably going to be asked to create one in Mylyn. Most of the internet associates the name Jenkins with a certain Leeroy who went into a World of Warcraft battle wielding little more than an attitude and a chicken. I hope that in this battle less damage is done to the consumers of this otherwise winning CI technology.
Watch Tasktop webinars
p
by Mik Kersten at February 04, 2011 12:27 AM
February 03, 2011
Anthony Hunter
GMF Runtime turns 20
This week had lots of Eclipse release activity. We are winding down the Helios service release two by promoting RC2 this week. We also also in the middle of Indigo promoting M5 this week. Double release duty.Seems like a good time to update the Graphical Modeling Project releases table. I maintain this to keep my sanity keeping track of all the version numbers of the projects and dependencies.A few things stood out.Indigo will be the 20th release of the GMF Runtime at Eclipse. That is a lot of releases. And that does not include the releases internal to IBM before we open sourced the platform to GMF.It is also noted that the GMF Runtime has yet to do a major version change. We have managed to be API backward compatible for the entire lifetime of the GMF Runtime project.That is a long history of stability for a platform and I know the products built on our graphical modeling platform are appreciative of this.
by Anthony Hunter (noreply@blogger.com) at February 03, 2011 09:50 PM
Ian Skerrett
Top 10 Fastest Rising Solutions on Eclipse Marketplace
Eclipse Marketplace Client (MPC) is becoming a popular way to install new plugins into Eclipse. There are 265 solutions available from MPC, so a great selection is developing. I recently blogged the top 10 solutions on Eclipse Marketplace but I thought it would be interesting to discover what are the new solutions people are finding on Eclipse Marketplace.    Therefore, I present the top 10 Fastest Rising Solutions during the month of January on Eclipse Marketplace.
The top 4 new solutions added to Eclipse Marketplace during the month of January were:
Eclipse Color Theme – this plugin has an amazing 1243 installs in the first month.  Very popular!
SpringSource Tool Suite 2.5.2  - a very respectable 859 installs in January
MouseFeed -  298 installs and seems like a handy plugin to remind developers about keyboard shortcuts
JPA Diagram Editor – 231 installs in January and a new Eclipse project
What were the existing solutions that had the biggest jump in overall rank?  Below are the 6 that made the biggest jump  from December to January.
Apache IvyDE™
Mylyn Mantis Connector
Quick JUnit
SVEditor
Debug Visualisation for Eclipse
Eclipse Metrics
If you haven’t tried Eclipse Marketplace Client, try it out and discover an easier way to install Eclipse solutions.  If you already used Eclipse Marketplace, why not check out some of these new solutions.
p
by Ian Skerrett at February 03, 2011 09:10 PM
Prakash G.R.
Adding a new editorAction for Orion
In case you have not heard it yet, Orion is the new Web IDE from Eclipse. In a blog entry introducing Orion, I said that this one is going to stand out from the crowd and going to rule the world. Why can't the other Web IDEs do that? Because, Orion, walking in the path of Eclipse, will provide the ability to customize and extend. Now with Orion 0.2 M5, you can extend the editor and provide your own editorAction. This is the first and only "extension point" available, but for sure, more will follow.
For this tip, we are going to add a Dictionary look up action to the editor. The action will open up Google Dictionary in a popup window for the selected text in the editor. Yes, popup windows are so ugly, and a div would be lot better, I'll do the beautification later, so for now disable your popup blockers.
Read More...
From Eclipse Tips
Like the tip? Subscribe via RSS or Email or Twitter
by Prakash G. R. (noreply@blogger.com) at February 03, 2011 07:35 PM
Ankur Sharma
Self help with API Tooling Reports (Part I): Generating the API Use report
API Tools is part of Plug-in Development Environment. Itprovides tooling support for tracking and managing your APIs and dependenciesand can generate various reports. The Eclipse help discusses here about how to set it up.What we will discuss here is how to generate various reports and making sense out of them.Generating the API Use reportAPI Use report is the simplest of the report. It tells what APIs are referenced (used) by a given profile. A profile can be an API Baseline, a Target Definition or a directory containing an Eclipse product or just some plug-ins.PDE provides an External Tools configuration wizard to run this report. The wizards can be launched from the Run menu - gt; External Tools - gt; External Tools Configurations...This will open the External Tools Configurations wizard. Select 'API Use Report' from the left pane and press the 'New' launch configuration button.The snapshot below shows the settings for an RCP product.AnalyzeYou can choose an API Baseline, a Target Definition or a directory to run the report on. The report is a set of XML files. To make it human readable, there is an option to generate HTML report out of any existing API Use report.Search ForHere you control what to look out for. The 'References to' takes a regular expression which will be used to match the APIs source. In this example the report will lookout only for the API originating out of bundles whose name starts with 'org.eclipse.'API references: The APIs used in your productInternal references: Marks the non-API - one coming from internal packages.Illegal API Use: Usage that breaks the restrictions marked using JavaDoc tags.Search InThis controls the search scope. The APIs references will be searched only in the plug-ins that match the regex provided here,ReportingThis is self explanatory. The report will be churned out as a hierarchy of.folders and XMLs in the output location. And if checked for 'Create HTML reports', they will be generated too. The report is saved inside the folder 'XML' in the report output location. While the HTML reports are inside the folder named 'HTML'.
by Ankur Sharma (sharma.ankur@gmail.com) at February 03, 2011 05:49 PM
Cedric Brun
2011 - The Thrill
One- two-three, one-two-three.. 2011 begins ... one-two-three..Is that waltz ? Clearly 2011 is starting with another kind of tempo: a fast and dynamic one !Fred Madiot just joined Obeo, you probably already met him at an Eclipse Conference and know him through the Eclipse Modisco project. He is joining us to develop the business through the Obeo Designer and Obeo Agility offers, we're quite excited about this and happy to get him on board !Speaking about getting on board , we still have room for internships, if you're interested in working on innovative open-source projects focused on modeling and app modernizations, feel free to contact us !Now on to the 2011 subjects: as french we like to cook, here is a taste of what is going on :You already know we're involved in many Eclipse projects, 2011 will see the launch of a new project named Intent [proposal] within the on-vitamin project Mylyn. This project is transforming the tedious and boring task of documenting software into a useful and easy process. You can have more information looking at the [Intent EclipseCon Talk], the [Wiki] (we're filling it up), [blog post fromAlex] or simply asking in the [Eclipse Forum].The Acceleo Team is working restlessly on enhancing the tooling (which is already awesome by the way). The wiki has been reworked, my favorite page is the [Features Matrix] (credits to eGit release reviews docuware) which will give you a nice overview of what is available and how. If there is one page to look at, it's this one !You saw [EEF in action] lately, the 0.9.0 is in the process of being released (currently in RC), this version will be the reference build for the upcoming Obeo Designer 5.0 ! If you're monitoring git in Eclipse, you might have seen the general project rush on this new infrastructure ! EMF Compare successfully did the move, you can now easily [fork it] and experiment at will ![Patrick] also joined the team and actively worked on getting a compare release which includes the MPatch support I blogged about [lately].Speaking about compare you can expect user interface enhancements, merge stabilization and dedicated UML support for this year. Coming soon in another blog post !As I said : exciting times and dynamic tempo !
by Cédric Brun (noreply@blogger.com) at February 03, 2011 03:40 PM
Eclipse Riena
How to query Bugzilla with Java
For a project I’m currently developing I wanted to query the Bugzilla database to include information about current bugs into the application. The obvious solution that comes to mind is using Mylyn. But this proved more difficult than expected. There seems to be no good documentation and the Bugzilla code is buried pretty deep. Eventually, I came up with this snippet that I wanted to share.
The setup is pretty easy, provided you use an Eclipse that already has the Mylyn feature installed. The RCP download includes all required bundles. Just create a new plugin project and add the following dependencies:
org.eclipse.mylyn.bugzilla.core
org.eclipse.mylyn.tasks.core
org.eclipse.mylyn.commons.net
Create a new test case and insert the following snippet. Running this test will print a list of bugs with their ID, priority and title. The fun part is that you can create any query by copying the URL from Bugzillas web interface and use it as BUGZILLA_SEARCH_STRING.
This does not appear to be the official way to do this, hence the annotation. If you have a better version to do this, I’m very interested as my post on the Mylyn newsgroup went without an answer.
@SuppressWarnings("restriction")
public class MylynBugzillaTest extends TestCase {
private static final String BUGZILLA_URL = "https://bugs.eclipse.org/bugs";
private static final String BUGZILLA_SEARCH_STRING = "/buglist.cgi?product=Riena amp;bug_status=NEW";
private final static String USERNAME = "";
private final static String PASSWORD = "";
public void testConnect() {
if (USERNAME.isEmpty() || PASSWORD.isEmpty()) {
fail("Please provide username and password.");
}
final TaskRepository repository = new TaskRepository(BugzillaCorePlugin.CONNECTOR_KIND, BUGZILLA_URL);
final AuthenticationCredentials credentials = new AuthenticationCredentials(USERNAME, PASSWORD);
repository.setCredentials(AuthenticationType.REPOSITORY, credentials, false);
final TaskRepositoryManager repositoryManager = new TaskRepositoryManager();
final TaskList taskList = new TaskList();
final RepositoryModel repositoryModel = new RepositoryModel(taskList, repositoryManager);
final IRepositoryQuery repositoryQuery = repositoryModel.createRepositoryQuery(repository);
repositoryQuery.setUrl(repository.getUrl() + BUGZILLA_SEARCH_STRING);
final TaskDataCollector collector = new TaskDataCollector() {
@Override
public void accept(final TaskData taskData) {
final TaskAttribute attribute = taskData.getRoot();
final Integer id = Integer.valueOf(taskData.getTaskId());
final String description = attribute.getAttribute("short_desc").getValue();
final String priority = attribute.getAttribute("priority").getValue();
System.out.println(id + " : [" + priority + "] " + description);
}
};
final BugzillaRepositoryConnector connector = new BugzillaRepositoryConnector();
final IStatus status = connector.performQuery(repository, repositoryQuery, collector, null,
new NullProgressMonitor());
assertEquals(IStatus.OK, status.getCode());
}
} p
by Stephan Mann at February 03, 2011 10:57 AM
Eclipse Announcements
Announcing the EclipseCon Hot New Product Showcase
This year at EclipseCon, the Hot New Product Showcase will feature new
Eclipse-based products that were released in the last 12 months. EclipseCon attendees will have a chance to see these new products in action and then vote for the
'Hot New Product Award'.
Any company, open source project or individual that has introduced a new Eclipse-based product in the last 12 months is welcomed to participate in the Showcase.
The product can be applicable to any market or industry. There are lots of great examples of Eclipse-based products in the mobile industry, cloud market, biometric research,
financial industry, advanced research, healthcare and many more. This is your chance to showcase your new product, so sign-up today. p
February 03, 2011 09:25 AM
Ekkehard Gentz
why I’m not using a great eclipse project …
…or why documentation is important
remark: the goal of this blog post is to report my experiences from my very personal POV and to help that projects can be more attractive to developers and perhaps also helping some developers how to solve problems if the TargetPlatform doesn’t work as expected
if you’re a member of an Open Source project perhaps you know this phenomen: someone is new on your newsgroup, asks questions and suddenly he/she disappears. there’s a chance that he/she isn’t a satisfied consumer of your project.
let me tell you a short story from my experiences last days:
as you probably know, I’m working on enterprise and mobile solutions, where for the enterprise site I prefer Eclipse RT projects like Equinox, Riena, … and at mobile site at the moment I’m focused on BlackBerry Java development. (not forget to mention Eclipse Modeling projects like MWE, Xpand/Xtend or Xtext helping me to solve my requirements to develop great apps in a short timeframe)
if developing mobile Business APPs, then you not only have a mobile APP – there’s always the need to communicate with a server and most times you have to support a bunch of protocols. The task I had to solve was communicating to a server from a mobile using TCP Socket. on BlackBerry devices this can be a ‘direct’ TCP Socket connection from the device to a server or a connection thru BES (BlackBerry Enterprise Server)
what do I need for Socket Connections:
should fit into my Equinox OSGI server
easy to be added to my TargetPlatform
using Declarative Services to be flexible
EPL licensed because I always provide core parts of my work under EPL
I googled to see if there’s a ready-to-go OSGI solution and found some TCP Socket servers but not OSGI – ready and in many cases not compatible with EPL.
but hey – I know that TCP Socket isn’t the only connection I need – there’s this great Eclipse Project supporting all kinds of communication: ECF (Eclipse Communication Framework)
at first I visited the ECF project homepage to see if there’s such a thing like a simple TCP Socket Server available but didn’t found one, then I asked in the NewsGroup and got an answer very soon: yes, ECF is using TCP Socket in many cases and I should take a look at the Generic Server.
because working on RT projects I need all to be available in my Target Platform. this should be easy for an eclipse RT project (I thought)
looked at the project sites to find installation docs how to do this but only found the update site.
to avoid all side effects I started with a fresh 3.6.1 EPP Modeling installation and created a new TargetPlatform based on the IDE, then I added the update site to my Target Platform definition. at first I checked that required software should be included.
unfortunately this runs into errors:
ok – nice try but then let’s try it without checking “include required software” – but this doesn’t help because after setting the Target Platform the ECF plug-ins are not resolved.
because there’s no documentation and I’m not getting answers to this from the newsgroup I started to try out some combinations.
btw: did all work using the normal update site and also the nightly builds.
after adding Equinox Target Components and Eclipse RCP SDK to my TargetPlatform:
it looks better and only some plug-ins were not resolved:
hint: if you read some of my blog posts about Eclipse Target Platforms you probably know that the “Target Platform State” view is your helper in these cases.
I found 3 problems:
required bundle org.apache.log4j as dependency from org.apache.zookeeper
missing javax.xml
missing org.eclipse.ecf.core.util in version 3.2.0
1. log4j: I don’t want to discuss now if required bundle or import package is better, but there are some good reasons for dependencies to logging frameworks to use import package because you never know which bundle will provide the log4j packages. in my case I’m using SLF4J where’s a bundle available to do this. ok  - I opened a bugzilla (335784) to change this and there’s some work on this. for now I solved this and imported the bundle org.apache.zookeeper into the workspace, opened the MANIFEST.MF and changed it. also I added my SLF4J and Logback bundles.
2. the missing javax.xml: thats also easy to solve. perhaps you know that you can add bundles on-the-fly to your Target Platform without knowing who’s providing it. You can ‘Add Artifacts’ (on the Mac CMD-ALT-SHIFT-A to get this view:)
simply enter javax.xml and by magic it’s added to your Target Platform
3. missing constraint: org.eclipse.ecf.osgi.services.distribution tries to import the package org.eclipse.ecf.core.util in version 3.2.0. This package was provided by org.eclipse.ecf bundle, but this bundle exports the package without a version number so it couldn’t be resolved. again as a good citizen I opened a bugzilla (335786). to help me in the meantime I imported org.eclipse.ecf.osgi.services.distribution into the workspace and removed the version from import-package-dependency. this was fixed very soon from ECF – so if using the N-Builds it should be there soon.
great: all ECF PlugIns resolved – so I created my OSGI launch config and really I got the Generic Server running
now the real work can start: to see how to get a TCP Socket Server running from ECF. …worked thru the code of GenericServer and found that there’s a ServerManager created in Activator.  worked thru this code to find out where I can add my classes to get the Socket Connection and work with ServerSocket and Socket. found out that I can define properties (like port number) in xml or extension registry. decided to use the xml – but trying to connect from outside doesn’t work. found out that there was a bug in an if-else construct and the xml was never read. again opened a bugzilla, added the solution and got soon answers inside the bugzilla.
but I wasn’t satisfied to hear ‘this ServerManager is outdated, only for backword compatibility, we know there’s no documentation but we have no resources…‘
uuups: no time to declare it as deprecated ?
THIS was the point I decided to stop evaluating ECF and started to write an (OSGI aware) TCP Socket Server by myself. will blog about this and provide sources.
I spent more time trying to find out what happens inside ECF (without finding the solution) then developing it by myself.
ECF is a great project and I can imagine that you can do all what you want, but from my POV it’s more important to have documentation to guide new users then always adding new features or changing the way how it works.
comparing my experiences with another RT Project like Riena – there are lightyears between Riena and ECF.
Riena provides
well documentation
installation-hints-to-get-target-platform running
many different examples to be run as eclipse project or client-server
wizards to create your own project based on Riena technologie
uncount unit tests
…and Riena is also a very complex project …but it’s really fun
remark: the only goal of this blog post is to give the ECF team some hints to become better. it also may be that I don’t found the right informations from wiki. and maybe if you’re looking for another kind of communication it will run out of the box from ECF.
the good things: work on my reported bugzilla happens soon after reporting – even on the weekend – thx to the ECF team
—————————————————————————————————————————
Filed under: Eclipse, OSGI, Riena p
by ekkescorner at February 03, 2011 08:20 AM
February 02, 2011
Andrew Niefer
Embedding the Orion Editor
Yesterday I wrote a blog post which contains a few snippets of Ant code. If you have java-script enabled, those snippets should be nicely formatted with line numbers and some basic syntax highlighting.Those code snippets are actually being shown using the Orion Editor embedded into my blog post. Granted, using the full editor here is a little over-kill since we aren't doing very much with it, but this was an interesting exercise.Here is the javascript I wrote to do this:/*******************************************************************************br / * Copyright (c) 2011 IBM Corporation and others.br / * All rights reserved. This program and the accompanying materialsbr / * are made available under the terms of the Eclipse Public License v1.0br / * which accompanies this distribution, and is available atbr / * http://www.eclipse.org/legal/epl-v10.htmlbr / *******************************************************************************/br /function findOrionElements(tagName){br / var elements = [];br / var tags=document.getElementsByTagName(tagName);br / for(var i=0;i lt;tags.length;i++) {br / if(tags[i].getAttribute('name')==='orion') {br / elements.push(tags[i]);br / }br / }br / return elements;br /}br /br /function createEditors() {br / //find all pre elements named 'orion'br / var elements = findOrionElements('pre');br /br / br / for(var i=0; i lt; elements.length; i++) {br / var element = elements[i];br /br / //extract the text from inside the prebr / var text = "";br / for( var j=0; j lt; element.childNodes.length; j++ ) {br / var nodeName = element.childNodes[j].nodeName;br / if (nodeName === "#text")br / text += element.childNodes[j].nodeValue;br / else if (nodeName === "BR" )br / text += '\n';br / }br / br / /* Create the editor: br / - parent is the containing div elementbr / - readonly by default, but can specify class="writable"br / - use the given stylesheet */br / var parentNode = element.parentNode; br / var elementClass = element.getAttribute('class');br / var editor = new eclipse.Editor({br / parent: parentNode, br / readonly: !(elementClass amp; amp; elementClass.indexOf('writable') gt; -1),br / stylesheet: "http://download.eclipse.org/e4/orion/js/org.eclipse.orion.client.editor/editor.css"br / });br /br / // use javascript styler for now, there is no html/xml syntax highlighting yetbr / var styler = new eclipse.TextStyler(editor, "js");br / // add a ruler with line numbers to the left sidebr / var lines = new eclipse.LineNumberRuler("left", {styleClass: "ruler_lines"}, {styleClass: "ruler_lines_odd"}, {styleClass: "ruler_lines_even"});br / editor.setText(text);br / editor.addRuler(lines);br /br / //fix the height of the containing divbr / parentNode.style.height = (editor.getLineHeight() * (editor.getModel().getLineCount() + 1)) + 2 + 'px'; br / }br /}br /This code is looking for all lt;pre name='orion' gt; elements and creating editors to replace them. These elements should generally be contained inside a lt;div gt; element. HTML for a replaceable section would look like this: lt;div gt; lt;pre name="orion" class="writable" gt;br / var hello = "Hello World!";br / alert(hello);br / lt;/pre gt; lt;/div gt;This example above was made writable by adding "class='writable'" to the lt;pre/ gt; element. Inside the lt;pre gt; element, all ' lt;' should be escaped as ' amp;lt;' and all ' gt;' as ' amp;gt;'.As a final step, to get this working on blogger.com, I combined my javascript together with:a href="http://git.eclipse.org/c/e4/org.eclipse.orion.client.git/tree/bundles/org.eclipse.orion.client.editor/web/js/editor.js"org.eclipse.orion.client.editor/web/js/editor.jsabr /a href="http://git.eclipse.org/c/e4/org.eclipse.orion.client.git/tree/bundles/org.eclipse.orion.client.editor/web/js/model.js"org.eclipse.orion.client.editor/web/js/model.jsabr /a href="http://git.eclipse.org/c/e4/org.eclipse.orion.client.git/tree/bundles/org.eclipse.orion.client.editor/web/samples/rulers.js"org.eclipse.orion.client.editor/web/samples/rulers.jsabr /a href="http://git.eclipse.org/c/e4/org.eclipse.orion.client.git/tree/bundles/org.eclipse.orion.client.editor/web/samples/styler.js"org.eclipse.orion.client.editor/web/samples/styler.jsabr / and minified it all using the Google Closure compiler. I hosted the resulting .js file on download.eclipse.org and added the following lines to the bottom of my blog post: lt;script type="text/javascript" src="http://download.eclipse.org/e4/orion/js/org.eclipse.orion.client.editor/orion-editor.js" gt; lt;/script gt;br / lt;script type="text/javascript" gt;document.onload=createEditors(); lt;/script gt;br /If someone visits the post without javascript enabled, then they don't get the nice formatting on the code snippets, but at least they are still inside lt;pre gt; elements which give them some basic formatting.
by Andrew Niefer (noreply@blogger.com) at February 02, 2011 11:44 PM
Nick Boldt
Visualizing OSGi Dependencies
Yesterday I blogged about how to find dependencies in features on plugins or features using a shell script to rip through feature jars.
But maybe you're less commandline, and more visual? Well, it may be over three years old, but there's a way to visualize plugin interdependencies using Ian Bull's PDE Dependency View. Frankly, I'm amazed this isn't already a core feature in PDE (and correct me if it is).
To use this tool, simply install it from:
http://download.eclipse.org/eclipse/pde/incubator/visualization/site
After installing and restarting, hit CTRL-3 and type "Graph" to find the "Graph Plug-In Dependencies View". (It's also available from Window gt; Show View gt; Other... (ALT-SHIFT-Q,Q) under Plug-in Development, if you prefer to kick it old-school.)
Next, right-click in the view or hit the "Focus on" button in the view, and select the plugin on which you want to focus.
Now you can browse up or down through plugins to explore dependencies.
For example, to see what plugins depend on a given plugin, such as org.eclipse.tm.terminal, click the "Show Callers" button in the view.
Or, to see on which plugins org.jboss.ide.eclipe.as.rse.ui depends, click the "Show Callees" button in the view. You can shift-click on nodes to highlight them for emphasis, or click and drag them around.
p
by nickb (nickboldt@gmail.com) at February 02, 2011 10:21 PM
Egon Willighagen
Accessing Google Spreadsheets from Bioclipse
I am almost done refactoring two year old code for the Open Notebook Science Solubility project, which converted its data from the Google Spreadsheet into RDF, for the Beautiful Data book chapter.Posted via email from Egon's posterous
by Egon Willighagen (noreply@blogger.com) at February 02, 2011 09:06 PM
Andrew Niefer
Overriding PDE/Build with the Ant Import task
PDE/Build has a number of places where you can run custom ant scripts during the build.The general pattern is the you would copy one of the customization templates from org.eclipse.pde.build/templates/headless-build into your builder directory and then modify the file as required. For simple builds it is often unnecessary to copy these files at all and PDE/Build will just use its original copy.If you only have a small change to make to the customization scripts, then it can be cleaner to not copy the template file and instead use Ant's Import task.Using Import to make minor changesThe ant Import task allows for overriding a target from the imported file. As an example, the Eclipse SDK includes the Build Id in its about box. The About Box contents come from "about.mappings" files inside plug-ins.What we want to do is after getting all our source from CVS, we do a quick replace in all the about.mappings files to update them with the build id.Instead of copying the customTargets.xml file into our builder, we create our own that contains just the following:builder/customTargets.xml: lt;project name="customTargets overrides" gt;br / lt;import file="${eclipse.pdebuild.templates}/headless-build/customTargets.xml"/ gt;br / br / lt;target name="postFetch" gt;br / lt;replace dir="${buildDirectory}/plugins" value="${buildLabel}" token="@build@" gt;br / lt;include name="**/about.mappings" / gt;br / lt;/replace gt;br / lt;/target gt;br / lt;/project gt;br /${eclipse.pdebuild.templates} is a property that is automatically set by PDE/Build and it points the folder containing the template files. This small snippet is much cleaner than copying the entire customTargets.xml just to add a few lines.This pattern can make for smaller and neater build scripts, but it turns out that this can also be a very powerful tool for modifying PDE/Build's behaviour.Here is the MagicDuring M5 milestone week, the Orion builds began failing about 90% of the time. The failure was "Unable to delete directory" in the middle of packaging ant scripts that are generated by PDE/Build. This seems to have been caused by an overloaded/lagged NFS server (or disk array).When building a product for multiple platforms with p2, PDE/Build installs the product into a temporary directory, zips it up, deletes that directory, and then repeats for the next platform using the same temporary directory. If there is a problem deleting the directory then we are in trouble because even if we could ignore the problem, the next platform will be contaminated with contents from the previous one.In order to work around the problem, we need to modify a target named cleanup.assembly which simply performs an ant lt;delete/ gt; on the temporary directory. The problem is, that this target is in the middle of the PDE/Build generated configuration specific packaging scripts. A deeper understanding of how these scripts work is required.Package Script OverviewWhen running a product build, the generated package scripts are organized per platform that we are building for. As an example, if we are building for windows, mac and linux, then we would have the following scripts:package.org.eclipse.pde.build.container.feature.all.xmlbr /package.org.eclipse.pde.build.container.feature.linux.gtk.x86.xmlbr /package.org.eclipse.pde.build.container.feature.macosx.cocoa.x86.xmlbr /package.org.eclipse.pde.build.container.feature.win32.win32.x86.xmlbr /The "org.eclipse.pde.build.container" portion of the file name comes from this being a product build. In a feature build this would be the name of the top level feature being built. The first (*.all.xml) script is the main entry point for the packaging process. Each of the other scripts do the packaging for each platform. Every one of those platform specific scripts contain a cleanup.assembly target that needs to be modified.Script DelegationThe top level packaging scripts does not call all the others directly, rather it uses a kind of delegation through the allElements.xml file. This file can be copied to your builder and modified to change the archive name or perform pre or post processing on the archive.For each platform, the top level packaging script will call allElements.xml/defaultAssemble (or a platform specific assemble.*.[config] target if one is defined) passing it the name of the platform specific packaging script to invoke.This is where we can insert our change in order to override the platform specific packaging scripts.The Modified allElements.xml fileWe copy the allElements.xml file from org.eclipse.pde.build/templates/headless-build/allElements.xml into our builder and change the "defaultAssemble" target to look like this: lt;target name="defaultAssemble" gt;br / lt;ant antfile="${builder}/packageOverride.xml" dir="${buildDirectory}" gt;br / lt;property name="assembleScriptName" value="${assembleScriptName}" / gt;br / lt;property name="archiveName" value="${archiveNamePrefix}-${config}.zip"/ gt;br / lt;/ant gt;br / lt;/target gt;br /The name of the platform specific packaging script is specified by the ${assembleScriptName} property. Instead of calling this directly, we instead call a script of our own "packageOverride.xml" and pass it the script name. Product builds normally use their own allElements.xml provided by PDE/Build which also sets the archive name based on the configuration being built. Since we will be using our own allElements.xml file, we also set the archive name here.Product Builds (using org.eclipse.pde.build/scripts/productBuild/productBuild.xml) are hardcoded to use their own copy of the allElements.xml file. In order to change this we must set a property allElementsFile which points to our copy. This property must be set before invoking productBuild.xml, which means setting it on the command line, or in a wrapping ant script. This is not necessary when doing a feature build.The new packageOverride.xml scriptThe allElements.xml delegation script has now been modified to invoke our own packageOverride.xml script. Our script looks something like this:packageOverride.xml: lt;project name="package.override" default="main" gt;br / lt;import file="${buildDirectory}/${assembleScriptName}" / gt;br /br / lt;target name="cleanup.assembly" gt;br / lt;condition property="doAssemblyCleanup" gt;br / lt;or gt;br / lt;not gt; lt;isset property="runPackager" / gt; lt;/not gt;br / lt;contains string="${assembleScriptName}" substring="package." / gt;br / lt;/or gt;br / lt;/condition gt;br / lt;antcall target="perform.cleanup.assembly" / gt;br / lt;/target gt;br / lt;target name="perform.cleanup.assembly" if="doAssemblyCleanup" gt;br / lt;exec executable="mv" dir="${buildDirectory}" gt;br / lt;arg value="${assemblyTempDir}" / gt;br / lt;arg value="${buildDirectory}/tmp.${os}.${ws}.${arch}" / gt;br / lt;/exec gt;br / lt;exec executable="rm" dir="${buildDirectory}" gt;br / lt;arg line="-rf ${buildDirectory}/tmp.${os}.${ws}.${arch}" / gt;br / lt;/exec gt;br / lt;/target gt; br / lt;/project gt;br /Here, we import the package script that was passed to us from allElements.xml, each time the packaging script calls us, we will be importing a different script. We inherit all the generated targets and override the cleanup.assembly target. Our modified version moves the temporary folder to a different location before trying to delete it. If the delete fails, that is ok because it is no longer in the way of the next platform. I used the native 'mv' and 'rm' hoping that they would behave better with a slow NFS server.The packageOverride.xml script must specify default="main" as that setting is not inherited.It is important to note that this override also affects the generated assemble.* scripts which are very similar to the package scripts. The assemble scripts also have an cleanup.assembly target which is getting overridden here. However, that target is only supposed to run during assembly if we are not going to be doing packaging. This is why we need a condition here to make sure the temporary folder is only deleted when it should be. The condition I used here would be wrong for feature builds where the top level feature name contains "package." because the generated scripts in a feature build contain the top level feature id.Final NotesThe change I have outlined here mas made to fix a specific problem with the Orion build. Care must be taken when applying these techniques to other problems and builders.The exact details here have been modified from the changes I actually made, so I have not actually tested the scripts as they are written above. Specifically, the condition on the overridden target has been added.This specific problem can also be fixed in pde.build itself, this is tracked by bug 336020.
by Andrew Niefer (noreply@blogger.com) at February 02, 2011 09:01 PM
Donald Ralph
Welcome ZeroTurnaround to the Eclipse Foundation
ZeroTurnaround OÜ has just recently joined the Eclipse Foundation as a Solution Member.The company, based in Tartu, Estonia and Prague, Czech Republic, is committed to making Java more productive by building innovative, cutting-edge productivity technologies that lower expenses and overhead for Java teams. Simplifying both the development and production processes with unique Rebel Technology(tm), JRebel and LiveRebel integrate directly into the JVMs, application servers and development tools of the world’s leading financial, web application, and technology firms. The flagship product is called JRebel, which allows Java developers to see changes to their code instantly without redeploying. With surveys showing that an average of 17% of each coding hour is lost due to unnecessary container restarts, JRebel has grown into a Java development productivity tool demanded by companies of all sizes. The company's upcoming product, LiveRebel, enables an enterprise production environment with 0% downtime for updating running apps. Customers include many global financial services providers, including the Bank of America and JP Morgan Chase, as well as American Airlines, Lufthansa, Volkswagen, LinkedIn, HP, Siemens, Logica, Kayak, Oracle, IBM, and more.We appreciate ZeroTurnaround's membership and look forward to many joint activities.PS: Find JRebel on the Eclipse Marketplace client in your Eclipse IDE (search for "JRebel") or go here for more info: http://marketplace.eclipse.org/content/jrebel-eclipse
by Ralph Mueller (noreply@blogger.com) at February 02, 2011 04:55 PM
Ed Burnette
Red Gate: We could not make the free model work for us as a commercial company
If you’re a .NET developer, chances are you’ve heard of .NET Reflector, a decompilation, debugging, and reverse engineering tool for managed code. Originally written by Lutz Roeder, .NET Reflector was acquired by Red Gate in August 2008. At the time, James Moore, Red Gate’s general manager of .NET Developer Tools said:“Our commitment is to maintain an amazing free tool that will continue to benefit the community while seeking input from users on ways to make .NET Reflector even more valuable.”In a sure-to-be controversial decision, the company is preparing to renege on that commitment. This morning, Red Gate Software announced that it will charge $35 for the basic edition of .NET Reflector 7, scheduled for release in early March. According to Neil Davidson, co-CEO of Red Gate,“We provided .NET Reflector without charge for two-and-a-half years, but unfortunately could not make the free model work for us as a commercial company. Charging this nominal amount â about the price of a tank of gas in the U.S. â will enable us to dedicate a team of developers to make sure that Reflector remains a valuable, up-to-date tool over the long term.”See also: Video with Greg Tillman and Simon Galbraith on the future of .NET Reflector.I sat down with Greg Tillman from Red Gate’s marketing team to get their side of the story…Next: Why the free model didn’t work gt; p
by Ed Burnette at February 02, 2011 02:05 PM
Egon Willighagen
DIY: Running R from within Bioclipse
Important: this blog post is about a development version of Bioclipse, not about the stable 2.4 series. See also Gilleain's comment for this post.Arvid has done an excellent job in setting up Hudson for Bioclipse, which is not so trivial as for Maven projects. With the R functionality I blogged about earlier today moved to the bioclipse.statistics repository, things are automatically build when new patches hit the repository. And Hudson doesn't just compile the code, it also exports binaries. The main Bioclipse products build can be downloaded here (Windows, Linux, OS/X; if you need more, please let use know). And, all the additional features got automatically uploaded to individual update sites, very much like Maven projects getting pushed to a Maven repository.So, here's an Bioclipse-R install guide for the adventurous (i.e. Christian, Rajarshi and Rebecca, perhaps Juuso :). I will describe it from a Debian GNU/Linux perspective.First, make sure you have R and rJava installed. I strongly recommend the versions from sid/unstable (2.12 and 0.8-8), which are more stable here than those from testing:$ apt-get install r-base-core/sid r-cran-rjava/sidThen you download the nightly build of Bioclipse 2.5.x from Hudson, e.g. for my 32bit Linux:$ cd /tmpbr /$ wget http://pele.farmbio.uu.se/hudson/job/Bioclipse.product/lastSuccessfulBuild/artifact/tmp/bioclipse/net.bioclipse.platform_feature_2.4.0-eclipse.feature/Bioclipse.2.5.0.linux.gtk.x86.zipbr /$ unzip Bioclipse.2.5.0.linux.gtk.x86.zipbr /$ cd Bioclipse.2.5.0.linux.gtk.x86/But before we boot Bioclipse, we first need to tell it where to find the R instance, and we need to set two variables for that: R_HOME and java.library.path. The latter is set via the bioclipse.ini file, by adding this line to the end:-Djava.library.path=/usr/lib/R/site-library/rJava/jriThe other is an environment variable and can be set with:$ export R_HOME=//usr/lib/RThen Bioclipse can be started:$ ./bioclipseThe first thing to do is install the R Feature. To do this open the Install New Software... dialog from the Help menu, and add (with the Add button) the Bioclipse Statistics update site on Hudson at this Location (copy/paste the Location URL into the below dialog):When back in the Available Software dialog, select the new update site, and mark the Bioclipse-R Integration feature to be installed:After the install is completed, which will require a reboot of Bioclipse (why?!?!), you can open the R console by opening a dialog from the Window - gt; Show View - gt; Other... menu:The R Console will then show up as view, as depicted in my earlier post.Loading of libraries, like running library("rcdk") or library("pls"), crashes the whole thing if you use R and rJava from Debian testing, and silently fails with those from unstable. It's on my agenda.
by Egon Willighagen (noreply@blogger.com) at February 02, 2011 01:56 PM
Holger Staudacher
Equinox/RAP WAR Products has moved. Hello Eclipse Libra…
A while ago I introduced you to my Google Summer of Code 2010 project, the WAR Products. I really appreciate your participation with feedback and bugs. It showed me that there is a real need for this tooling, so I’m proud to announce that the WAR Products development will not continue in the RAP Project.
You may think, “WTF? Odd thing to be proud of.” But, it really does make sense . The WAR Products were never targeted to be part of RAP, primarily because the tooling is not RAP specific. It eases the deployment of Server-Side Equinox applications. And this kind of application does not necessarily have to be a RAP application.
Three months ago a new Eclipse project was announced. It’s called Libra or formerly “OSGi Enterprise Tools” (it had to be renamed ‘Libra’ because of legal issues). I don’t want to repeat the project goal here because Kaloyan (the Libra project lead) does a much better job with this than I could. You can read about the project in this proposal. Libra passed the project creation review a while ago and provisioning by the eclipse.org webmasters is ongoing. So, why am I talking about Libra here?
There is a simple reason.  Because of one sentence from Kaloyan about Libra, I thought it would be the perfect project to contribute the WAR Products to.  “Libra tries to close the gap between PDE and WTP”.  This maps exactly to the WAR Products as the tooling tries to ease the deployment of Equinox-based applications on Servlet-Containers or JavaEE Application Servers.
Additionally there are plans to extend the tooling with a WTP integration to enhance the creation of a WAR Archive with automated deployment functionality, without adding explicit dependencies to WTP. And where can this development be done better than in between PDE and WTP?
Yesterday I committed the WAR Products to the Libra git repository after it passed the IP process successfully. I also set up a temporary p2 repository from which you can install the tooling (Eclipse 3.7 M4+ required). Of course we’re trying to push Libra in the direction of Indigo. If this works you will soon be able to install the WAR Products from the Indigo Repository. Please keep in mind that the bundle ID’s have changed during the move. So, if you had installed the sneak-preview from this blog post, please uninstall the tooling before installing the Libra version. It’s really worth getting the new version because of many bug fixes and enhancements which are included. Please feel free to file bugs, but this time against Libra
Please note: To use the WAR Product’s full functionality you need to add the Equinox Server-Side SDK to your target or set RAP 1.4 M5 as your target environment. There is no longer a “requiredBundles.zip” that you need. Use this temporary p2 repository to install the WAR Products: http://download.eclipsesource.com/~hstaudacher/warproducts/3.7/ p
by Holger Staudacher at February 02, 2011 11:56 AM
Boris Bokowski
New features in Orion M5
We shipped a new milestone of Orion yesterday. For those who haven't heard about Orion yet, its goal is to build developer tooling that works in the browser, at web scale. The idea is to exploit internet design principles throughout, instead of trying to bring existing desktop IDE concepts to the browser.
There are two new features in this new milestone (download) that I would like to highlight:
the ability to install, as a user, editor actions supplied by third-party web sites, and
a very early integration with Firebug.
Editor Actions
In any decent editor, you'd want the ability to customize - adding new key bindings, new functionality, and changing its look. We have a first implementation that covers the first two of these, with an interesting twist: Editor actions can come from anywhere on the Internet!
Here is our favourite example, code formatting functionality for JavaScript files: Have a look at http://jsbeautifier.org, which hosts a JavaScript formatter that is implemented in JavaScript, and has been developed independently of Orion. It was astonishingly easy to add a little bit of glue code around it to make it available as a command in the Orion editor. Thanks to Einar Lielmanis, the author of this JavaScript code formatter, the resulting code is even hosted at jsbeautifier.org!
To make the command available in your local installation of Orion, you would go to http://localhost:8080/view-registry.html, which is a special page showing your installed plugins. Enter http://jsbeautifier.org/orion/jsbeautify.html in the text box and click on Install. The new plug-in should now be listed in the tree. Now navigate back to the Orion code editor, or hit reload on an existing Orion code editor in another tab, and enjoy the new action available in your editor's toolbar. You can read more about this in Simon's blog - he implemented a lot of the frameworky stuff to make this possible.
This is a humble start of being able to pull functionality from all over the web into your development environment, which itself is web-based. Note that the server wasn't involved at all!
One of the next steps will be to add this extensibility to our navigator as well, and to expand what's possible from an editor action. Currently, editor actions see the selected text, the complete editor buffer, and the start and end of the current selection. They can change just the selection, or the complete buffer and the current selection. With just this minimal API, there is already a lot you can do - implement traditional editor actions, but also navigate within the editor buffer, change the contents of the entire buffer, or even contact a server for more heavy-duty processing.
If you have interesting ideas for what you could do with this, contact me (on Twitter, the #eclipse-orion channel on IRC, or the Orion development mailing list) and I'll give you an account on our demo server at http://orion.eclipse.org - we are slowly adding users there - so far it's by invitation only.
Firebug Integration
If you are doing web development, Firebug is one of the indispensable tools these days. It does much more than the usual code debugger: yes, it lets you set breakpoints, single-step, and inspect variables visible from your stack, but it also supports monitoring HTTPS requests, inspecting the browser's DOM, looking at CSS styles, and more.
So instead of implementing some kind of debugger inside of Orion, it would be much better to integrate with existing debuggers that already exist. The question of course is, what does it mean to integrate? We have two main "integration points" in mind: being able to open the Orion editor on a file you see in Firebug, and synchronizing breakpoints between Firebug and Orion.
So far, we've worked on the first one only, as a start. It involved a little bit of code on the Orion side, and a little bit of code on the Firebug side. Thanks a lot to John J. Barton, the Firebug lead, for working with us on this! To try it out, you need to install a Firebug 1.7 alpha version as well as a Firebug extension called Dyne. The detailed instructions are on the Firebug wiki. Once installed, you should be able to open http://orion.eclipse.org/file/org.eclipse.orion.client.core/static/view-registry.html while Firebug is active. Open the script panel, you will see a new button "Edit". Clicking on this button opens the Orion code editor in a new browser tab.
Clearly, there is still ways to go before this flows nicely, but it's a great start. What I like in particular is that this is all based on an extra header Orion is sending, from which Firebug can construct the URL which contains the editor. This means that any web-editable resource could be edited in this way, just by adding custom headers - there is nothing Orion-specific that had to be put into the Firebug code base!
Looking Ahead
Both of these features illustrate the direction we want to take with Orion, and they align perfectly with our development principles. I'll quote two of them here:
Reuse existing technologies - Don't re-invent the wheel if one already exists that we can integrate (through HTTP, or as open source that we consume), even if we could build a better wheel ourselves.Low barrier of entry for adopters - We don't want to force people to have to re-write code just so that it fits into Orion, nor do we want them to have to re-write just so they can use one of our components.Looking ahead, here is our list of ideas for additional integrations with existing web-based services:
Paste selected text to pastebin.com.
Create a new Gist from the current editor buffer.
In the navigator, add an action to smush (remove unnecessary bytes from) an image.
Multi-select a few files and click on an action to generate a CSS sprite.
Upload the current editor buffer to codepad, and insert the result from running the code at the bottom of the editor buffer.
Send files to the W3C validator.
Look up a word in a thesaurus and display alternative names.
I'd love to hear your suggestions. What should we add to the list? What should we work on first? Would you be interested to work with us on a similar integration? You can contact me on Twitter, the #eclipse-orion channel on IRC, or the Orion development mailing list.
by Boris Bokowski (noreply@blogger.com) at February 02, 2011 07:04 AM
Stephan Herrmann
Bye, bye, NPE
As I announced earlier most of my time for the JDT currently goes into static analysis, more specifically into analyzing various issues relating to null references.
Since the compiler can’t read our minds on whether we intend to allow null for a method parameter, a method return etc. we should give it a little help: annotate types in method signatures with either @Nullable or @NonNull, thus creating a contract between a method and its callers.
With such contracts it is possible to write code that is provably free of NPEs — wouldn’t that be great?
Let null contracts become mainstream
The theory and some tools for checking null contracts have been around for a while. I think it is time that the Eclipse Java compiler will make this feature directly available within your favorite IDE.
Towards this goal work in bug 186342 has made good progress, but some issues still need discussing and experimenting before this feature can be released into the JDT.
First prototype available
The current prototype is available for download — see these steps for installing into a fresh Eclipse SDK 3.7 M5.
What the prototype supports:
@NonNull and @Nullable annotations for method parameters, method return and local variables, seemlessly integrated with the existing flow analysis of the JDT compiler.
Inheritance of null contracts with the option of compatible refinement in subtypes.
Configuration of a global default (either @NonNull or @Nullable) to reduce the number or required annotations.
Configuration of specific qualified names for these annotation types to support compatibility with (some) other tools
A few quickfixes for adding obviously missing annotations.
If you like to play with these existing features you’re highly welcome to install the plugin and give feedback in the bug.
If you want to see the full story you may want to wait for some more items from my agenda:
Null annotations for fields
Nullity profiles for libraries
Configurability of the default annotation per package and per type.
More quickfixes
Behind the scenes
There’s a second piece of good news in this development: before this feature gets approved for committing into JDT head, I was faced with the usual choice to either evolve the feature outside CVS or create a branch. Since I didn’t like the efforts incurred by either approach – regarding maintenance as well as deployment – I chose the third option: Object Teams.
I transformed my recent patch from the bug into a regular OT/Equinox plug-in. The Object Teams based solution not only avoids the double maintance associated with branching but also makes the specific code for this feature much easier to read because it is localized in exactly one module. Also, the plug-in can be easier comsumed because it can be packaged and deployed independently of the concurrent evolution of the JDT.
By the way: those interested in these and other cool things that can be done with Object Teams: don’t miss our EclipseCon tutorial:
Hands-on introduction to Object Teams
See you at
p
by stephan at February 02, 2011 06:00 AM
Simon Kaegi
Orion M5 and Plugins
We delivered Orion M5 yesterday and I wanted to talk briefly about a cool new feature that you can try out for yourself, namely Plugins. Similar to the Eclipse Desktop, in Orion you use plugins to extend the environment. What's different is that an Orion plugin is not something you install into your server. Instead, an Orion plugin is a link to an external site that contains an HTML document and some plugin JavaScript.The ideas are best illustrated by working through a very quick example where we add a JavaScript beautifier plugin.Download an Orion stable build unzip and run it. Here's some instructions to help get you started.Connect and login into Orion - http://localhost:8080/Navigate down to org.eclipse.orion.client.core/static/js/compiled/coding-editor.js -- shortcutThink to yourself oh snap minified JavaScript, I'm hosed.Open a new tab and go to the Plugin Registry page -- http://localhost:8080/view-registry.htmlPaste the following URL (http://jsbeautifier.org/orion/jsbeautify.html) into the install box on the right and click install. If you mess up click the red "X" to clear the registry and start again.Return to your editor tab and refresh the page.You should see a new "bat" icon on the action tab right next to coding-editor. Click it.Bask in the glory that is well formatted JavaScript with minified variable namesAll the interactions here are browser-side with no server involvement other than to provide the HTML page. Instead, Orion's opening an iframe (and eventually a web worker) and then using cross-document messaging to get the plugin to perform the "editorAction".In terms of the code required to write a plugin you need just one script "orion-plugin.js" as well as your implementation. Here's the HTML for another very simple "editorAction" that you can try out. lt;!DOCTYPE html gt;br / lt;html gt;br / lt;head gt;br / lt;meta http-equiv="Content-Type" content="text/html; charset=UTF-8" gt;br / lt;script type="text/javascript" src="orion-plugin.js" gt; lt;/script gt;br / lt;script gt;br / window.onload = function() {br / var provider = new eclipse.PluginProvider();br / provider.registerServiceProvider("editorAction", {br / info : function() {br / return {br / name : "UPPERCASE",br / img : "/favicon.ico",br / key : [ "u", true ]br / };br / },br / run : function(text) {br / return text.toUpperCase();br / }br / });br / provider.connect();br / };br / lt;/script gt;br / lt;/head gt;br / lt;body gt; lt;/body gt;br / lt;/html gt;br /Files: upper-plugin-example.html, orion-plugin.jsFor the moment in M5 "editorAction" is our one and only extension point. We're working on M6 now and figuring out other places where we want to offer similar extensibility. If you have ideas or better still would like to try your hand at writing plugins we'd love for you to get involved. Feel free to visit us on IRC at #eclipse-orion and pipe-in.
by Simon Kaegi (noreply@blogger.com) at February 02, 2011 04:16 AM
Mik Kersten
Prediction #7: Web-based code editors become viable, cloud-based IDE platforms remain a pipe dream
A couple of years ago, a web-based code editor called Bespin was the rage at EclipseCon, and has been reborn in the form of the Cloud9 IDE for JavaScript. Eclipse re-embraced the push towards web-based IDE technologies with the introduction of a new code editor named Orion. While activity is again heating up on this front, do not expect the enterprise developer’s IDE to be running in the browser this year. What we will see is web-based advances in specific IDE use cases, ranging from code editors for DevOps to GUI builders for mobile, with most developers staying within the comfort and native UI of their desktop IDE.
Apart from the OS, the IDE may now be the most complex piece of software running on your desktop computer. Eclipse pushes the limits of the UI element handling of the desktop OS as well as the classloader model of common JVMs. What makes an IDE platform even harder to port into the browser is the need for extensibility, ranging from interaction with the filesystem to shared data models of the large variety of code and ALM artefacts that constitute an application.
Just as mobile applications are constantly pushing the limits of the hardware behind our 3.5” handheld screens, the IDE tool suite continues to push the limits of the hardware driving dual 24” displays. Third party plug-in developers need to be very aware of the performance of their extensions to Eclipse so that they don’t bring an Intel Core i7 CPU with 8GB of RAM to a crawl. The current generation of browser-based JavaScript runtimes is not up to the task of running the IDE platform as we know it. But we are starting to see the first crop of high-performance web-based code editors. Between the drive towards cloud hosting of applications and the push to lower the barrier to entry for mobile development, there will be plenty of incentive for vendors to provide SaaS offerings that incorporate key parts of the application development experience.
The 15M or so professional developers (Evans Data, 2009) will spend their day in Eclipse and Visual Studio, but these IDEs will begin to feel more like a connected Rich Internet Application (RIA) than a desktop-bound dinosaur. The data accessed by the open source developer, including source code, tasks and builds, is already cloud hosted. Eclipse extensions like Tasktop Enterprise mash up the web browser experience with the rich IDE experience. The professional IDE will start feeling more like a connected and offline capable Mozilla Thunderbird or Microsoft Outlook, with collaboration and planning facilities taking a front seat alongside social coding tools. Just as iOS has found the sweet spot between native experience and web service-based data sources, so will the IDE.
Outside of enterprise application development, domains where a simplified tool stack is applicable will start seeing web-based IDE features. Xcode is one or two order of magnitude less complex than a full-blown enterprise Java IDE. Palm’s Ares project was the pioneering example of how effective combining Bespin functionality with a JavaScript GUI builder for webOS could be for providing a simple user experience to hobbyist mobile developers. Even our Smalltalk forefathers would be impressed with an environment that supports authoring JavaScript widgets in a JavaScript-based GUI builder. Given the lack of a clear winner for JavaScript development environment on the Eclipse front, JavaScript will continue to be a natural target driving progress on moving IDE functionality into the browser. But the amount of work here should not be underestimated, as a lot of what already exists in the desktop-based IDE will need to be re-created to get to the sort of fidelity and breadth of tool support that’s now taken for granted.
Cloud ALM hosting with the connected IDE and Browser-based clients
On the cloud hosting front, key parts of ALM data such as source code, builds and tasks, are already starting to be hosted in a unified manner, as exemplified by the upcoming Code2Cloud offering. Some stakeholders in the development process, such as DevOps and QA engineers, will start to benefit from Eclipse Orion-style code editors accessing and fixing entries in Spring config files without launching the IDE. This will lead to easier management of production since the need for console access for these sorts of tweaks will be removed.
Looking further out, the increasingly connected IDE will have all of its configuration data hosted, making the experience of the first launch of Eclipse similar to that of the first launch Skype, where entering credentials causes the rich client to instantly provision the user’s desktop. The division of labour between web and desktop based access of software artefacts will improve, with some content that was previously browser-bound, such as Scrum task boards, being supported within the IDE. The mobile hobbyist, casual web developer, and specific stakeholders such as the DevOps engineer, will see nearer term benefits from the growing convergence of the browser and the IDE.
Watch Tasktop webinars
p
by Mik Kersten at February 02, 2011 12:52 AM
February 01, 2011
Jason van Zyl
Navigation improvements in the m2eclipse XML POM editor
If you use the m2eclipse POM XML editor, you will be interested to know that we’ve made a number of improvements to the interface.   Yesterday, we introduced some addition auto-correct options and automatic integration of the POM XML editor and the Artifact Search dialog.   Today, we focus on improved navigation options now available in the m2eclipse POM XML Editor. By making use of the current effective POM, we are able to give you more information right at your fingertips.
The screenshot below shows options that are available to you by hovering over on an expression in the m2eclipse POM XML Editor.
When hovering your mouse on top of a managed dependency, we show the currently resolved version of the artifact (dependency or plugin) and also where the artifact is managed (the model’s coordinates).
Invoking a hyperlink on the managed artifact gives you some new options as well. If the location is in another pom.xml file, that POM file is opened for you, and the cursor is placed at the location of the artifact’s definition.
Next to the preexisting option to open the artifact’s POM, you can now also navigate to the location where the artifact is managed. Let’s see where it leads us.
As you can see the artifact’s managed location is using an expression for declaring the version. Here you can again hover your mouse over the expression to see what it resolves to in the effective POM. To get to the definition of the property, just invoke the hyperlink again (Ctrl-Left Click on most platforms, Cmd-Left Click on MacOSX). See the next screenshot.
After hyperlinking, you reach the definition of the antlr.version property and you can finally change the property value and upgrade your ant-antlr dependency. If you find any issues with this feature or have a great idea for improvement, please don’t hesitate to file an issue in the eclipse.org bugzilla.
These improvements will be available from the Indigo repository at the end of this week as part of the M5 release. If you are adventurous you can try the temporary Hudson build which can be found here.
  p
by mkleint at February 01, 2011 05:00 PM
Doug Clarke
Using JPA 2.0 in WebLogic 10.3.4
Starting with the Oracle WebLogic 10.3.4 release it is now possible to upgrade to using JPA 2.0. The release includes TopLink 11.1.1.4 (with EclipseLink 2.1.2).Since WebLogic 10.3.4 is a compliant Java EE 5 implementation it is required to ship out of the box with support for EJB 3.0 and thus JPA 1.0. If you wish to upgrade your install to allow JPA 2.0 use you must follow install a small patch, which is documented here.If you are making use of Oracle Enterprise Pack for Eclipse the new 11.1.1.6.1 includes support for using the JPA 2.0 capabilities.Doug
by Doug (noreply@blogger.com) at February 01, 2011 04:10 PM
Jonas Helming
The curious case of VisibleWhen
Almost every Eclipse developer has used it, but I have seen many cases, where the VisibleWhen tag is just copied. It is used to define the visibility of the menu item of your plugin. As an example you could show a specific menu item in the navigator right click menue of a certain type (e.g. a Java File). This post describes a typical example of the VisibleWhen in detail, thanks to Stephan for wrapping thing up.A very easy way to test the VisibleWhen condition is to register an example command on Java elements. They can be created in the target (the compiled and started Eclipse instance). In this example I register an example command in the right click menue of an ICompilationUnit (Java Class) and an IJavaProject (Java Project). The following screenshots shows these two elements in the target.The following example shows the menue entry, if one IJavaProject is selected.br / lt;menucontribution allpopups="false" locationuri="popup:org.eclipse.jdt.ui.PackageExplorer" gt;br / lt;command commandid="menucontributions.commands.sampleCommand" gt;br / lt;visiblewhen checkenabled="false" gt;br / lt;and gt;br / lt;iterate ifempty="false" operator="and" gt;br / lt;instanceof value="org.eclipse.jdt.core.IJavaProject" gt;br / lt;/instanceof gt;br / lt;/iterate gt;br / lt;count value="1" gt;br / lt;/count gt;br / lt;/and gt;br / lt;/visiblewhen gt;br / lt;/command gt;br / lt;/menucontribution gt;br / lt;/extension gt;br /-By setting the attribute checkEnabled to true the menu will check if the corresponding handler has been enabled; if it has been enabled then it will show the menue entry, otherwise it will not. - is combining the conditions: In this case the "iterate" condition AND the "count" condition have to be true. Otherwise the item isn't shown.- iterates over all selected elements and checks the conditions underneath for every element. If you directly right click an item, only one element is selected. If multi-selection is allowed, many elements can be selected on right click. ifEmpty=false means that if nothing is selected, the menu item isn't shown. operator="and" says that the conditions (in this case there is only one instanceof condition, but there can be more) must be true for all selected elements. operator="or" will show the menue entry, if the condition is true for at least one selected element.-instanceof checks for every selection if the selected element is an instance of the type someClass in this case org.eclipse.jdt.core.IJavaProject.- With count you can set the number of selected items. If more or less are selected, the menu item isn't shown.You can also use th following parameters:* Arbitrary number of items ? Zero or one item + One ore more items ! No itemsThe following example shows the menue entry if exactly two items are selected and both items are either an ICompilationUnit or an IJavaProject: lt;visiblewhen checkenabled="true" gt;br / lt;and gt;br / lt;iterate ifempty="false" operator="and" gt;br / lt;or gt;br / lt;instanceof value="org.eclipse.jdt.core.IJavaProject" gt;br / lt;/instanceof gt;br / lt;instanceof value="org.eclipse.jdt.core.ICompilationUnit" gt;br / lt;/instanceof gt;br / lt;/or gt;br / lt;/iterate gt;br / lt;count value="2" gt;br / lt;/count gt;br / lt;/and gt;br / lt;/visiblewhen gt;br /
by UNICASE (noreply@blogger.com) at February 01, 2011 04:06 PM
Erkki Lindpere
JRebel 3.6 for Eclipse Released
Today we (ZeroTurnaround) released version 3.6 of JRebel, our productivity tool for Java developers that eliminates many redeploys and restarts. Along with the core JRebel release, we made a major update to JRebel for Eclipse. With this release, we hopefully made getting started with and using JRebel for Eclipse super-easy, although I’m sure there are still things we can improve in the future.
There were quite a few things we did to make setting up JRebel for Eclipse easier. First, the plug-in is now available from the Eclipse Marketplace, making finding the plug-in and the installation process easier. Second, there is now a new plug-in that embeds JRebel itself — meaning that you will not have to install it separately, the Marketplace install contains everything you need. Third, with this release we also started signing our Eclipse plug-ins, eliminating one more step from the install process.
We also made other improvements to our Eclipse integration, including
improvements to the debugger integration — stepping should now perform exactly as you expect
support for more launch configurations (WTP server editor sections and JRebel tabs for launch configurations), including OSGi and Virgo launch configurations
small UI improvements, making it easier to find logs, change JRebel’s settings, see licensing information and redeploy statistics
numerous other small improvements
If you are not already using JRebel, we offer evaluation licenses to JRebel for Eclipse users and free licenses to open source and Scala developers. But be warned: once you give it a try, you’ll never look back!
p
by Erkki Lindpere at February 01, 2011 03:48 PM
Martin Lippert
Upcoming Event: JAX 2011
I am pretty happy to participate in the upcoming JAX 2011 conference in Mainz, Germany as part of the Eclipse Tools Day (organized by Lars Vogel). In my talk "Spring Tooling - What's cooking" I will talk about the stuff I am doing in my job all day: building Eclipse-based tooling for the Spring development platform. Aside of showing some of the nice features we built into this tooling (like direct deployment to different PaaS clouds and nice improvements for annotation-based spring programming) I will also take a look under the hood. I will take a look at the challenges and problems building this tooling on top of the Eclipse platform and how we adressed them.See you at JAX 2011 in Mainz!
by Martin Lippert (noreply@blogger.com) at February 01, 2011 12:45 PM
Meinte Boersma
A New Hope
(Sorry about the thoroughly geeky title: I couldn’t resist )
Yesterday was my last tenured day at my former employer (go and check LinkedIn to find out which one it was) and today is the first day of my new life as an independent. This represents a huge challenge to me, but one I simply had to take on in order to have a chance of getting my message out to the business world -my former employer wasn’t really helping with that.
Obviously, my focus will be model-driven software development (MDSD) and domain modeling in a mix of consultancy, a bit of DSL evangelization (e.g. through this blog) and a bit of creation of/contribution to open-source projects. Apart from that, I’ll be getting my hands dirty with some mobile app development.
But the next two weeks I’ll be practicing my callous off for a gig with an international instrumental progressive band called Relocator: check here for more info about the gig. That also means I’ll be somewhat undercover/incommunicado simply because I’m locked away with a guitar in my hands. Don’t worry, I’ll be back
p
by meinte37 at February 01, 2011 08:45 AM
Nick Boldt
HOWTO: Find osgi dependencies in features
Say you're trying to build something with Tycho amp; Maven 3 and while resolving dependencies before compilation, you're told:
[INFO] [Software being installed:
org.eclipse.tm.terminal.local.feature.group 0.1.0.v201006041240-10-7w312117152433,
Missing requirement:
org.eclipse.tm.terminal.local 0.1.0.v201006041322
requires
'bundle org.eclipse.cdt.core 5.2.0'
but it could not be found,
Cannot satisfy dependency:
org.eclipse.tm.terminal.local.feature.group 0.1.0.v201006041240-10-7w312117152433
depends on:
org.eclipse.tm.terminal.local [0.1.0.v201006041322]]
To quickly verify where this dependency is coming from, you can go look into the feature.xml for the org.eclipse.tm.terminal.local feature jar... but if you don't have it installed, this is somewhat more cumbersome; besides, you then have to unpack the jar before you can look inside it.
And maybe that feature contains a number of OTHER dependencies that you'll also need to resolve in your target platform when building. Sure, there are UI tools to do this within Eclipse, but when you're working on remote servers sometimes UI isn't available.
Workaround? Assuming you have a mirror of the update site(s) from which you're trying to resolve the dependency (eg., Helios) or can ssh to dev.eclipse.org, you can simply run a quick shell script to do the investigative work for you:
$ cd ~/downloads/releases/helios/201009240900/aggregate/; ~/bin/findDepInFeature "*tm*" cdt
./features/org.eclipse.tm.terminal.local_0.1.0.v201006041240-10-7w312117152433.jar
lt;import feature="org.eclipse.cdt.platform" version="7.0.0" match="greaterOrEqual"/ gt;
lt;import plugin="org.eclipse.cdt.core" version="5.2.0" match="compatible"/ gt;
lt;import plugin="org.eclipse.core.runtime"/ gt;
Where the script looks like this:
#!/bin/bash
# find plugins/feature deps by searching in some folder for feature jars, and searching through their feature.xml files for dependencies
# 1 - featurePattern - pattern of features to search (eg., "org.eclipse.tptp" or "\*" for all features)
# 2 - dependencyPattern - pattern of plugins/feature deps for which to search (eg., "org.eclipse.tptp.platform.instrumentation.ui")
# 3 - location - directory in which to search, if not "."
if [[ ! $1 ]]; then
echo "Usage: $0 lt;featurePattern gt; lt;dependencyPattern gt; lt;location gt;"
echo ""
echo "Example: $0 tm.terminal cdt"
exit 1
fi
# if no location, look in current dir (.)
if [[ $3 ]]; then location="$3"; else location="."; fi
# if no featurePattern, search all features for dependencyPattern
if [[ ! $2 ]]; then featurePattern="*"; dependencyPattern="$1"; else dependencyPattern="$2"; featurePattern="$1"; fi
rm -fr /tmp/findinfeature/; mkdir -p /tmp/findinfeature/features/
for f in $(find "$location" -type f -name "*${featurePattern}*" | egrep -v "pack.gz|source" | grep features | egrep "${featurePattern}"); do
#echo "$f [$featurePattern, $dependencyPattern]"
unzip -q $f -d /tmp/findinfeature/ feature.xml
# lt;import feature="org.eclipse.cdt.platform" version="7.0.0" match="greaterOrEqual"/ gt;
# lt;import plugin="org.eclipse.cdt.core" version="5.2.0" match="compatible"/ gt;
if [[ ! $(cat /tmp/findinfeature/feature.xml | egrep " lt;import" -A3 | egrep "plugin=|feature=" -A1 -B1 | egrep "\".*${dependencyPattern}[^\"]*\"" -A1 -B1) ]]; then
rm -fr /tmp/findinfeature/feature.xml
else
mv /tmp/findinfeature/feature.xml /tmp/findinfeature/${f}_feature.xml
echo "${f}"
cat /tmp/findinfeature/${f}_feature.xml | egrep " lt;import" -A3 | egrep "plugin=|feature=" -A1 -B1 | egrep "\".*${dependencyPattern}[^\"]*\"" -A1 -B1
echo ""
fi
rm -fr /tmp/findinfeature/feature.xml
done p
by nickb (nickboldt@gmail.com) at February 01, 2011 06:37 AM
January 31, 2011
Dariusz Luksza
I’m nominated for Top Contributor in 2011 Eclipse Awards
To be honest I haven’t been fallowing anything connected with Eclipse Community Awards, because I was thinking that this isn’t for me as em I a humble EGit commiter. But is seams that some one has different opinion on this, because I was nominated …
You can imagine my surprise when I got an email with information that I’m nominated for Top Contributor. I was totally shock! and can’t believe in this. But then I check Eclipse Community Awards Bulletin and I saw my name on the list of nominated contributors … I believed that this it is true.
I’m honored, I’m truly honored, no mater what the final results would be I’m honored with this nomination!
Finally I want to encourage you to take part in voting for Eclipse Community Awards, especially I encourage to vote on EGit project with was nominated in category: Most Innovative New Feature or Eclipse Project
p
by Dariusz Łuksza at January 31, 2011 10:26 PM
Heiko Behrens
pyKeynoteTweet: Participate in your Twitter backchannel while presenting with Keynote
Social media like Twitter and Facebook have changed the way we interact at technical conferences. You might have noticed that people are using their mobile devices and laptops quite a lot when attending sessions. In fact, they’re not impolite or rude – they just google up further information about the topic presented! As a speaker, you can help your audience to use your presentation even more efficiently by preparing a little take-away for them. Here is how.
A few months ago, I read Olivia Mitchell’s free e-book “How to present with Twitter (and other backchannels)” and stumbled across the tool keynotetweet she mentions throughout her advices. Unfortunately, the tool stopped working when Twitter changed its authentication mechanism to OAuth. Instead of modifying the bunch of AppleScript (well… you know) I decided to come up with pyKeynoteTweet.
The tool allows you to send out tweets while you give your presentation with Keynote. It does so by looking for the pattern
[twitter]your tweet[/twitter]
in your presenter’s notes. Each time a new slide with this pattern appears during presentation mode it sends out the payload. You can refer to other people (e.g. @hbehrens) or use #hashtags as you are used to. The script warns you for tweets that exceed the 140 character boundary of Twitter before you start your presentation and avoids repetitive tweets if you go back to a previous slide when questions arise.
Olivia Mitchell lists some benefits of using Twitter during your presentation and I can only encourage you to try it out. Not only does it help you to receive more feedback (some people do not like to speak up), and encourage your audience to spread your word (RT: your point). It’s also a good starting point for virtual discussions and digital relationships.
Download or fork pyKeynoteTweet on GitHub and let me know about your creative ways of using it.
By the way: My next talk complemented with this script will be at beyond tellerrand on Monday, 7 February. Stay tuned and follow me on twitter!
Links
pyKeynoteTweet on GitHub
e-book “How to present with Twitter (and other backchannels)” by Olivia Mitchell
p
by Heiko Behrens at January 31, 2011 09:22 PM
Denis Roy
EclipseCon: sometimes it's the small things
NOTE: This is an old post that was picked up by PlanetEclipse as a result of moving my blog.Sometimes it's the smallest things that can make a conference feel so much better.  The conference has only been "on" for two hours, and here's what I've noticed:Breakfast: Fruit!  Plenty of fresh fruit.  A cereal bar.  Pastries.  But fruit!Coffee: large cups that can hold more than 2 sips.  Folks can actually grab a cup and walk away from the fountain.Centralized: Everything is contained within the hotel itself, so you don't spend half your day walking around looking for the rooms.  Much easier to meet up with friends and colleagues.Props to the conference organizers who keep finding ways of improving an already great conference.
by Denis Roy (noreply@blogger.com) at January 31, 2011 06:24 PM
Denis Roy
Setting up a download server.. How much RAM do I need?
NOTE: This is an old post that was picked up by PlanetEclipse as a result of moving my blog.If you've been following along, you know that I received a bunch of hardware to upgrade Eclipse.org.   'Keep it in RAM' is my thinking with all this.  Currently, our servers spend a lot of time waiting for disk resources, so the benefit of keeping requests in RAM is twofold: cached files are served quickly, and disk resources are freed for faster access to disk.Right now I'm in the process of setting up a high-capacity download server to replace download.eclipse.org, so the question is -- how much RAM do I need?I started by examining the combined Apache logs of download.eclipse.org for any given day.zegrep "GET .* 200 " download.eclipse.org/access_log.3.gz | awk '{print $7}' gt; filelistbr /strongfilelist contains 2,439,051strong successful "GET" requestssort filelist | uniq -c | sort -nr gt; filelist-sortedbr /strongfilelist-sorted contains 73,184 entriesstrongSo each day our server only reads about 75,000 files -- but serves them 2.4 million times.  There is a huge potential for cache hits right there.  With a small perl script, I gathered the size (on disk) of those 73,184 files.  Total: 25G.#!/usr/bin/perlbr /br /open(FILE, " lt;filelist-sorted");br /while( lt;FILE gt;) {br /        $_ =~ s/\n//;br /        ($c, $f) = split(/ /, $_);br /        $size = -s "downloads" . $f;br /        print "$size $c $f\n";br /}So if I get 24G of RAM, I'm sure that most of the file requests will come from cache.  Actually, if I load up the numbers in a spreadsheet, I see a wicked long-tail distribution.  In fact, 134 files are fetched at least once each minute and account for 43% of all requests.  If you consider the RAM requirements of the OS and Apache, 24G would be great -- for today's needs.  What about next year?Considering it's cheaper to buy RAM when it's popular (commodity), I put 64G of RAM in the new download.eclipse.org.  It should be more than sufficient to hold the entire week's worth of download files, file attributes and such while keeping disk requests to a minimum.  It will also have plenty of RAM for the OS and Apache, even when things heat up in June.We're also moving to the Apache worker MPM for download.eclipse.org.  It is multi-threaded, so with high client counts, it consumes much less memory than the prefork model.  PHP files (which are only a very small fraction of the hits) will be served over FastCGI.So there you have it.  Your downloads won't necessarily be faster since we are limited by bandwidth, but they should begin faster.  The new setup will also free disk resources for those files that cannot always be cached, such as CVS, SVN and Git.  Win-win! p
by Denis Roy (noreply@blogger.com) at January 31, 2011 06:23 PM
Bob Balfe
Resources for AD201 – How the Jedi’s Do Plug-in Development
As promised, here is the list of resources referenced for the AD201 Lotusphere session.
You can drag and drop the following links to your My Widgets panel in the Notes client:
Attachment Viewer Widget
Mail Rules Widget
Multiple Database Search Widget
Referenced Project links:
TwitNotes
Attachment Viewer
Notes UI API Exerciser
Mail Rules
OAuthr ViewPart – not there yet!
OSGI Console Sidebar application
p
by Bob Balfe at January 31, 2011 04:36 PM
Max Rydahl Andersen
JBoss Developer Studio 4 CR1 available on Early Access!
The Early Access site for JBoss Developer Studio now contains CR1 free for download and if you want the JBoss Enterprise Application platform bundled you just need to and sign up for the early access program here.ImprovementsThis release contains a few improvements over the last couple of betas that are worth mentioning. Most of these stems from the change we made from using the horrible dropin feature of Eclipse to have a properP2 enabled Eclipse product build. This should make things like installation, startup and updates much smoother, simpler and in some cases faster.New Directory LayoutThere is no longer a seperate "eclipse" directory; everything related to JBoss Developer Studio is now in the "studio" folder andinstead of using raw eclipse to start you now uses the jbdevstudio, jbdevstudio.exe or the JBoss Developer Studio.app dependent on yourplatform to launch. If you have installed the EAP bundle jboss-eap still lives in lt;install gt;/jboss-eap.Runtime Detection/SetupYou can still use the "Server" page in the installer to setup JBoss server runtimes, but all this that was previously isolated in the installer is now also available from inside JBoss Tools under the Preferences for "JBoss Tools Runtime Detection". Here you can configure directories to scan for runtimes and it supports not only Server runtimes, but also standalone framework runtimes like Seam and Drools.Welcome ScreenYou will also now be greeted with a new shiny Welcome Screen:  ...and of course the latest stable fixes and features from JBoss Tools 3.2. Have fun!
by Max Rydahl Andersen (do-not-reply@jboss.com) at January 31, 2011 01:18 PM
Torkild Ulvøy Resheim
Eclipse Stammtisch Trondheim Q2-2011
Inspired by community meetings elsewhere in Europe and the growing adaption of Eclipse in Trondheim; my employer, Itema AS is sponsoring a Eclipse Stammtisch in the second quarter of this year. There will be at least four presentations followed by the intake of some frosty beverage. The agenda is not planned yet but we'll probably be talking about Git, modeling (EMF), build systems (Mylyn Builds) and Qt. Helping us with the presentations will be representatives from Marintek and NTNU.If you'd like to participate please let us know by filling out the RSVP.
by Torkild U. Resheim (noreply@blogger.com) at January 31, 2011 09:31 AM
Eclipse Announcements
Voting is Open for the Eclipse Community Awards
Nominations for the Eclipse Community Awards are complete and
voting has opened for the individual
and project category nominees. Congratulations to all the worthy candidates! Show your
appreciation to the people that have made Eclipse a stronger community by casting your vote.
More details about the awards and the nomination process can be found on the
awards page. Voting for the Eclipse Community
Awards will be open until February 25, 2011 at 5:00pm EST and the winner will be announced March 21, 2011 at
EclipseCon.
January 31, 2011 08:40 AM
January 30, 2011
Bob Balfe
LS11 – JMP103 – Plugin development Jumpstart
Nice crowd for the session, so far so good for Mikkel and Ryan!
p
by Bob Balfe at January 30, 2011 07:11 PM
Andrei Loskutov
Anyedit can sort text now
I've released a new 2.4.0 version of AnyEdit plugin. This version fixes incompatibility with Eclipse 3.7 M5 and contains a new great sort feature,
contributed by Clemens Fuchslocher.
Now the plugin has all kind of "sort" functionality. Thank you Clemens!
P.S.
BTW, we are still looking for a good Eclipse developer in Böbingen/Stuttgart area.
p
by Andrei Loskutov at January 30, 2011 09:45 AM
January 29, 2011
Miles Parker
Supporting Multiple Resource types with EMF Editor
The resource model is one of those aspects of the Eclipse Modeling Framework that is extremely powerful yet can seem way too complicated for us mere mortals to muck with. "But what if I break something?" The thing about powerful abstractions is that the more powerful they are, the more they do; and the more they do, the more systems they touch and -- somehow -- the more mysterious they become.  I'll propose a little law here which I am sure is not original: "any abstraction that is sufficiently powerful will be initially opaque". Just where are those levers we need to pull to get things to do what we want? As a highly leveraged framework, EMF is full of such abstractions. So how to get past that learning barrier?
Well, it takes some up front commitment, really, but there is a pretty simple heuristic to it: Decide the things you want to change, look through the generated code for where the things are that you might want to change, and experiment. Or wait for someone else to do the experimenting for you, which is the smartest strategy of all. Ergo, you must be smart, because you're reading this. So without further ado, let's take a look at how to do something extremely cool.
The basic scenario is this: there are a number of different data formats -- in EMF speak, "Resource Implementations" that might be appropriate for a given user and use case. By far the best example of this is dealing with the problem of data transparency vs. data efficiency. XML is (arguably) readable using any text editor, and it is definitely the format you want to be using when something goes wrong, for example a reference is bad or you have a problem with encoding. But memory footprint and load and save performance wise, it's a total dog. In contrast, Binary is the format you want to use when you have a lot of data and you need to use it, but good luck figuring out what's in it without your editor.
Here's something that I'll bet many people -- even those who have been using EMF for a long time -- don't know. I didn't. EMF has built in support for a very efficient Binary Resource model. But how can we use it? There is (not last time I checked anyway) no resource type entry in .genmodel for "Binary".
In fact, it turns out that it is ridiculously easy to replace the generated XML resource support with support for binary resources if you're willing to touch a bit of code. (I want to thank Ed Merks and Kenn Hussey for pointing me the way initially.) That's great, but now you have the problem of sticking the user with an unreadable binary format. Wouldn't it be cool to support both formats, so the user could take the same data and save it in the format most appropriate for his or her needs? It turns out that that's easy to do too, and it took me (much) less time to figure out then it took to write this blog post. And actually, I need to get on with it, because I'm working this weekend and I really don't want to be. So without even further ado, let's follow the heuristic I mentioned above.
First, we know that we need to support multiple resource types. How do we change that? Well, resources are setup in the foo.model plugin. In foo.util we can see the various factories. So we need to create two new pieces. (Actually, we don't have to do this, but it makes it a little easier to see what it happening.) So we could look at what the existing resource handlers are doing -- say FooResourceImpl -- and copy and modify it with the appropriate changes:
public class FooResourceImpl extends XMLResourceImpl {
    public FooResourceImpl(URI uri) {
        super(uri);
    }
}
Suggests that we probably want something like the below (although it's probably unnecesary):
public class FooBinaryResourceImpl extends BinaryResourceImpl {
    public FooBinaryResourceImpl(URI uri) {
        super(uri);
    }
}
I told you it was ridiculously simple. Similarly we want:
public class FooBinaryResourceFactoryImpl implements Resource.Factory {
    public Resource createResource(URI uri) {
        return new FooBinaryResourceImpl(uri);
    }
};
Now, we want to support two different kinds of files. We could do all sorts of funky stuff there, but let's keep it simple. We'll just use different file extensions. This part may seem just a bit mysterious, just because it involves a number of different artifact types. But first, we know that genmodel defines the file extensions. We can add one for the binary resources in the model section. Let's use "foo,foobin". We're only doing that for consistency because the real action is elsewhere. Since we're now dealing with editor stuff it makes sense to look there for what we want. And if we look at the FooModelWizard, we can see that there is a reference to _UI_FooEditorFilenameExtensions. That's the bit we want to change, and because genmodel won't write over .properties files, we'll need to edit it there:
[foo.editor/plugin.properties]
...
_UI_FooEditorFilenameExtensions = foo,foobin
...
We next need to tell the editor what to do with those binary files when it gets them. The natural place to do that is when we setup the editing domain for FooEditor, and we'll do it at the end of the method call:
/**
* This sets up the editing domain for the model editor.
*
* @generated NOT
*/
protected void initializeEditingDomain() {
...
editingDomain.getResourceSet().getResourceFactoryRegistry().getExtensionToFactoryMap().put("foobin", new FooBinaryResourceFactoryImpl());
}
OK, now the more challenging part. How to actually allow the user to select the file type? Again the obvious place to look is in new file wizard. We just need one change here, to tell the wizard what to do when the user selects the binary extension:
FooModelWizard
/**
* Do the work after everything is specified.
*
*
gt; gt; * @generated NOT
*/
@Override
public boolean performFinish() {
...
        // Create a resource set
        //
        ResourceSet resourceSet = new ResourceSetImpl();
gt; gt;resourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap().put("foobin", new FooBinaryResourceFactoryImpl());
...
}
Now, for extra credit, how can we let the user change the file type once a file has been created? Well, we know the user picks the file type in the editor, so let's look there. And here we go..we'll show the entire method, but it is only the first 15 lines or so that have changed:
/**
*
*
* @generated NOT
*/
protected void doSaveAs(URI uri, IEditorInput editorInput) {
    ResourceSet resourceSet = editingDomain.getResourceSet();
    Resource resource = resourceSet.getResources().get(0);
    if (!uri.fileExtension().equals(resource.getURI().fileExtension())) {
        Resource oldResource = resource;
        if (uri.fileExtension().equals("foobin")) {
            resource = new FooBinaryResourceImpl(uri);
        } else if (uri.fileExtension().equals("foo")) {
            resource = new FooResourceImpl(uri);
        } else {
            throw new RuntimeException("Unexpected resource type: " + uri.fileExtension());
        }
        resource.getContents().addAll(oldResource.getContents());
        oldResource.getContents().clear();
        resourceSet.getResources().remove(oldResource);
        resourceSet.getResources().add(0, resource);
    }
    resource.setURI(uri);
    setInputWithNotify(editorInput);
    setPartName(editorInput.getName());
    IProgressMonitor progressMonitor = getActionBars().getStatusLineManager() != null ? getActionBars().getStatusLineManager().getProgressMonitor()
: new NullProgressMonitor();
    doSave(progressMonitor);
}
All we are doing there is creating the new resource, moving the contents over to it and replacing the old resource with the new one. (Don't be afraid to muck with resources and resource sets, they aren't as fragile as you may think.) That's it. I'm sure I missed something here that I'll discover later, but everything works.
Back to the original use case. I needed to support the xml format because I expect people to use the data in the application in a lot of different ways. But I really needed the binary format because my application produces very large files and those files take a long time to load. (When you load these files in the editor, the UI is frozen.) One file took:
19 m, 57 s
Using the binary format improved that a little bit:
00 m, 00 s, 419 milliseconds
Part of that is due to the fact that reference resolution can be deferred, but the entire file can be easily navigated without perceptible delay. The whole user experience is dramatically altered. That's a lot of functionality to gain with really some pretty small changes! And that's why taking the time to grasp more complex abstractions is worth the effort. What's interesting is that once you understand them, they don't seem at all complex!
p
by Miles Parker (noreply@blogger.com) at January 29, 2011 11:13 PM
Dariusz Luksza
Show non-workspace resources in Git Change Set
Synchronize view in EGit doesn’t show non-workspace files from its very beginning. This issue seams to be very complicated and also it seams to require lots of hacking on team framework and eclipse API.
Few days ago Ilya Ivanov from Intland pushed into our gerrit a patch that should fix this issue. I was very surprised that this change is so small and simple. It only works partially because the compare editor cannot be launched for non-workspace files. In my opinion this patch cannot be merge into master branch without this core functionality, so today I spent about 3 or 4 hours hacking on that topic … and here are results:
As you can see, there is master pom file (with isn’t imported into eclipse workspace) in synchronize view and on the left hand side there is a compare  editor for it, showing what was changed ; gt;
Currently both patches are waiting for review in gerrit, but I think that they will be merged into master soon
p
by Dariusz Łuksza at January 29, 2011 09:46 PM
Mike Milinkovich
OpenJDK Governance
On Friday, Mark Reinhold, mentioned that I have recently spent some time helping to help flesh out a draft governance model for the OpenJDK community. As John Duimovich described it, our goal is for OpenJDK to be “…an open, transparent, and meritocratic project that can be run in a lightweight and efficient manner”. I think we’ve largely succeeded in getting there. But it is important to recognize that when the document is (soon!) made public that it is a draft. I expect that many people will have comments and feedback, and I look forward to hearing them.
I do not have a prior history of involvement with the OpenJDK community, so being asked to contribute to this process was both an honour and a pleasant surprise. But given that Eclipse is also a community which involves participants ranging from individuals to some of the world’s largest corporations I believe we have some experiences which are helpful and relevant to the governance of OpenJDK. I hope that I’ve made some useful contributions which help the OpenJDK community off to a great (re)start.
Filed under: Open Source p
by Mike Milinkovich at January 29, 2011 09:30 PM
Thomas Kratz
Building a web-startable cross-platform p2-installer
Have you ever had trouble with your customers downloading the wrong version of your eclipse product to their box? We had always trouble with 64bit windows with 32bit Java installed, no one can expect from customers to know what java version they have installed.So today I started off with a slighty customized version of the standard eclipse p2 installer. I got the 3.6.1 maintenance branch from the cvs repo, as current head doesn't compile against the 3.6 platform. I removed the shared install options, as they only would confuse users.The idea was to webstart the installer to give users an as easy as possible download experience. But the built-in mechanisms of eclipse give us some tedious manual work to do to build such a thing.First I created a feature containing all the plugins necessary to run the p2 installer, and added all the other platform plugins that are needed to support mac and both windows platforms. (We do not support linux by know, but that should be straightforward). One has to set the platform properties of the platform dependend plugins in the feature manifest manually, a task I always forget until I try to run the build.Then change the p2 installer product configuration to be based on features and add you newly created feature. Create a keystore if you do not already have one and follow the instructions from the eclipse help to create a webstartable application.Unfortunately the webstart export does not support multiple platform export, however if you have included the platform dependent plugins, you will find them in your feature.jnlp file, but with all version attributes set to 0.0.0Now do a second export of the feature, uncheck the JNLP creation option and export for multiple platforms. Leave the signing option on as we need signed jar files for webstart. Copy all the exported, platform dependend plugins from the export to you webstartable plugins folder. (You could get them from the delta pack as well, but then they wouldn't be signed with your key). Now the tedious work: replace the jar file path with version 0.0.0 in your feature jnlp wit the correct paths to your added plugins. The platform and architecture selection in the jnlp will already be there.To make the p2 installer work via webstart we need to do a third export. This time export the product for you main platform only and get the configuration directory from the export, copy it to the root folder of your webstartable export (simpleconfigurator needs a config file from there thats not included in the jnlp export).Set up your main jnlp file as suggested in eclipse help and add some properties for the p2 installer: lt;property name="org.eclipse.equinox.simpleconfigurator.configUrl" value="http://yourwebstarthostpath/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info"/ gt; lt;property name="org.eclipse.equinox.p2.installDescription" value="http://yourwebstarthostpath/installer.properties"/ gt;Don't forget to add your customized installer.properties file. Now upload this to your webserver and voila, we have a platform independent installation experience for our product.Don't mind to ask if you run into any troubles. Getting the jnlp files work properly is sometimes confusing.
by Thomas Kratz (eiswind@googlemail.com) at January 29, 2011 04:18 PM
January 28, 2011
Kim Moir
Implementing shared licenses with 3.7M5
This is the best Eclipse license I've ever seen.Image © chriscardinal, http://www.flickr.com/photos/disatasu/3243844762/ licensed under Creative Commons by-nc-sa 2.0Conversely, dealing with license files in Eclipse features is a bit painful.  Today, each time the Eclipse license changes, you need to copy the new license files to your features.  The license files included in the Eclipse SDK are highlighted below: These same files are included in the 46 features that the Eclipse and RT Equinox project builds.  This is very tedious to update when the license files change. Lots of copy and paste. The license text also appears in the feature.properties.In Eclipse 3.7M4,  the PDE and p2 teams added support for shared licenses. The license files will be copied from the license feature to the feature that refers to it.  In 3.7M5, I modified our features to use this shared licenses. For instance, the beginning of the feature.xml for the Eclipse SDK now looks like this: To implement this, I followed these steps.  1. Create a license feature. This feature doesn't include any bundles or features. It only stores the license files which its build.properties reference.   The feature.properties has only two properties - the licenseURL and license.  2. Update the existing features to reference the license feature.  Remove the license files from these features.  Remove the references to the license files from your feature's build.properties.  The values will be inherited from the build.properties of the license feature.  Remove the name and values of licenseURL and license from the feature.properties. These will be included from the license feature. Ensure that you don't have duplicate properties in the feature.properties of the license feature and feature your are updating. This will cause a build failure.3.  Update your map files to include to the new feature. You don't need to nest the feature in another feature to fetch it, this happens automatically. For example, this is where our license feature is locatedfeature@org.eclipse.license=v20110121,:pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse,,org.eclipse.sdk-feature/features/org.eclipse.license4. Run a test build. Fix typos until you have a clean build. Verify that all your features still include the appropriate license files.  There isn't an IU for the license feature included in the p2 repository.  The license text is included in the metadata.Note that you'll need to build with 3.7M5 bundles.  There was a bug in the 3.7M4 bundles that prevented shared licenses from working in generated source features.The advantage of this approach is that when the license files are updated, we'll only need to update the license feature.  We'll also have to increment the versions of the license feature in the referring feature, but that's a simple search and replace.  Some other implementation details: I could have also stored the copyright information in the feature.properties of the license feature. However, the copyrights of our features are not identical, so I didn't choose this approach. This may be useful for other teams. Thanks to the  PDE and p2 team for implementing this!Further referencesBug 306818 - Improve license support in p2.License mechanism description in wikiBug 332662 - Adopt new feature that allows to share the license file
by Kim Moir (noreply@blogger.com) at January 28, 2011 09:34 PM
EclipseLive
Upcoming Event: Automated Functional Testing with Jubula
Event Date: March 7, 2011 4:00 pm GMT-8Register Now
Alexandra Imrie (BREDEX)
 
Abstract:
Jubula provides automated functional GUI testing for Java and HTML applications. The project is aimed at functional testers who want to automate their black-box tests for SWT/RCP, GEF and Swing applications. The keyword-driven approach lets testers design, automate and maintain tests by dragging and dropping from a library of test actions. Test creation is quick and code-free, tests are easy to read, and the modular structure makes them easy to maintain, despite changes in an application's GUI.
Watch this webinar to learn about functional test automation for Eclipse applications using Jubula and to ask questions about the project.
Total running time will be approximately 1 hour
8:00 am PST / 11:00 am EST / 4:00 pm UTC / 5:00 pm CET - Convert to other time zones
Thanks to Adobe for contributing their Adobe Acrobat Connect product to host this webinar.
delicious | digg | dzone
by EclipseLive (lynn.gayowski@eclipse.org) at January 28, 2011 05:41 PM
Goulwen Le Fur
EEF 0.9 New cool feature part I : EEF Editors
Some weeks without any post on this blog because we done many changes on EEF to prepare an 0.9 version.Probably the most exciting new feature is the ability to generate EEF editors with one click from the EcoreTools modeler. This demonstration shows how it's easy to produce EEF editors with this new version :Next time, I will show you all the EEF editors features ...edit: Etienne added the sound part of this demo ! ;)
by Goulwen Le Fur (noreply@blogger.com) at January 28, 2011 04:49 PM
Erwin Tenhumberg
Creating a Custom SAP ME Web Service Utilizing SAP ME Public API
This blog post will provide a step-by-step guide for authoring your own custom web service that runs within SAP Manufacturing Execution (ME) via Eclipse/NWDS and utilizes SAP ME's public API. There any many ways to author web services within SAP ME - this is only one.
by Tim Drury at January 28, 2011 04:09 PM
EclipseLive
Eclipse SMILA Videos
SMILA Project
 
Abstract:
SMILA is an extensible framework for building search solutions to access unstructured information in the enterprise. Besides providing essential infrastructure components and services, SMILA also delivers ready-to-use add-on components, like connectors to most relevant data sources. Using the framework as their basis enables developers to concentrate on the creation of higher value solutions, like semantic driven applications.
The SMILA team has created a series of videos on the project for developers and decision makers. They cover topics such as how to develop an application with SMILA, documentation, what SMILA can do for your organization.
delicious | digg | dzone
by EclipseLive (lynn.gayowski@eclipse.org) at January 28, 2011 03:38 PM
January 27, 2011
Andrew Niefer
Building from Git
Git was introduced at Eclipse about a year ago. Projects are slowly migrating over to use git as the SCM system instead of CVS or SVN. When IBM made its initial contribution for the new Orion project, we migrated from internal CVS servers to git at eclipse.org. This post will give an overview of the changes I had to make to our releng setup to start building from git.There have been a few PDE/Build bug fixes in 3.7 to support building from Git. I recommend using a recent 3.7 build as your base builder. 3.7M5 is due out this week.General SetupThe Orion releng build is a relatively standard p2 enabled PDE/Build product build.There are a few things that need to be done to get the build working with git:Bootstrapping the builderGetting map filesFetching source from GitThe e4 builds consume source code from git repositories, but the releng project and map files are still in CVS. Only the 3rd step here was required for e4. The entire Orion project including releng project and mapfiles is in git so we need all three.Bootstrapping the BuildThe Orion releng builds run via cron job on build.eclipse.org. We need a small shell script that can get the Orion releng project from git and start everything off. We do this using the git archive command:br /git archive --format=tar --remote=/gitroot/e4/org.eclipse.orion.server.git masterbr / releng/org.eclipse.orion.releng | tar -xf -br /The build machine has local access to the git repository, if we were running from somewhere else, this would change to something like --remote=ssh://user@dev.eclipse.org/gitroot/...This will get the releng project into the current working directory, at which point we can invoke ant on it.Getting map files from GitPDE/Build uses map files to fetch our code from source repositories. The first step to this is getting the map files themselves.PDE/Build comes with default support to fetch map files from CVS which is controlled by a few properties (see Fetch phase Control). This obviously doesn't apply here. However, this step is fully customizable using the customTargets.xml file.All we need to do is copy the org.eclipse.pde.build/templates/headless-build/customTargets.xml file into our builder and modify the getMapFiles target. We can then use the git archive command to get our map files. It would look something like this:br / lt;target name="getMapFiles" unless="skipMaps" gt;br / lt;mkdir dir="${buildDirectory}/maps" / gt;br / lt;exec executable="git" dir="${buildDirectory}/maps" boutput="${buildDirectory}/maps/maps.tar"b gt;br / lt;arg line="archive -format=tar" / gt;br / lt;arg line="-remote=/gitroot/e4/org.eclipse.orion.server.git" / gt;br / lt;arg line="master releng/org.eclipse.orion.releng/maps" / gt;br / lt;/exec gt;br / lt;untar src="${buildDirectory}/maps/maps.tar" dest="${buildDirectory}/maps" / gt;br / lt;/target gt;br /Because the "| tar -xf -" we used earlier is a redirection done by the shell, that doesn't work when we invoke git from ant. Here we specify a file to hold the output of the archive command, this ends up being a tar file which we can just untar.Fetching source from GitPDE/Build has an extension point where fetch script generators for different repositories can be plugged in. The EGit project provides an implementation for this extension point.The org.eclipse.egit.fetchfactory bundle is available from the http://download.eclipse.org/egit/pde/updates-nightly p2 repository. Install that bundle into the eclipse install that is used to run your build.Git Map FilesOnce we have the egit fetchfactory, all we need to do is update our map files with entries for GIT. Here is an example map file entry from Orion:br /plugin@org.eclipse.orion.client.core=GIT,tag=v20110125-1800,\br / repo=dev.eclipse.org:/gitroot/e4/org.eclipse.orion.client.git,\br / path=bundles/org.eclipse.orion.client.corebr /tag is the tag to use when fetching the bundle from gitrepo is the path to the git repository. In order to omit the user from the repository path, the build needs to run as a user who has ssh access to the git repo at dev.eclipse.orgpath is the path within the git repository to the project we are interested in.Final DetailsThe EGit fetch factory works by cloning the git repository to a local directory, checking out the tag and then copying the project over to the build Directory. Builders can set the fetchCacheLocation property to specify a local directory where the git clones can be kept. This location may be reused from build to build to avoid having to re-download the entire repository each build."Nightly" builds are set up to build the latest code from HEAD. For CVS, this is usually accomplished by setting "fetchTag=HEAD" to override the map file entries. For Git you would use "fetchTag=origin/master". If you are using both CVS and GIT you can set both with "fetchTag=CVS=HEAD,GIT=origin/master".The Eclipse Platform team uses the releng tool plugin to manage their map files in CVS, there is not yet an equivalent tool for git. See the Orion Releng and E4/Git wiki pages for instruction on how to manage map files.
by Andrew Niefer (noreply@blogger.com) at January 27, 2011 09:51 PM
EclipseLive
Integrating HP Quality Center and IBM Rational Team Concert using Tasktop and Mylyn
Robert Elves (Tasktop)
 
Abstract:
Organizations deploying IBM Rational Team Concert (RTC) alongside HP Quality Center (QC) have been lacking a robust mechanism for federating and synchronizing defects and work items between IBM Rational products and HP ALM and Quality Center. Developers often have to enter information regarding their activities into multiple systems and managers lack the visibility and traceability that is needed to be effective. In this webinar, Robert Elves showed the audience how Tasktop Enterprise can be used to provide IDE integration and synchronization for RTC and QC to improve development team productivity and collaboration between developers and QA and provide visibility into both RTC and HP QC and ALM.
Presenter: Robert Elves, Tasktop Enterprise Integrations Architect and Eclipse Mylyn Committer
delicious | digg | dzone
by EclipseLive (lynn.gayowski@eclipse.org) at January 27, 2011 09:44 PM
Ed Burnette
Android 3 Honeycomb: Why this changes everything (and nothing)
A preview of Android 3.0 (Honeycomb) has finally been released. Developers can download the new platform and updated SDK tools and play around with it before devices such as the Motorola Xoom hit the market in February.First rumored at Google I/O 2010, and later demoed at CES, Honeycomb was designed from the ground up to support Android-based tablets. Does that mean it won’t run on smartphones too? Is it a fork, as suggested by Steven J. Vaughn-Nichols? Not according to the man behind the overhaul, Matias Duarte.See also:Android ‘Honeycomb’ 3.0: Hands on experienceAndroid 3.0 preview, SDK lands: Does this UI entice?Google has forked AndroidYou may remember Duarte as the designer of WebOS from his days at Palm. In an interview with Engadget earlier this month, he said:What you see in Honeycomb is absolutely the direction for Android… We have to serve all of Android’s needs. [For example,] If Android shows up on a car, you’re going to see the same kinds of improvements, the same design philosophy, the same usability improvements, the same new paradigms, new tools, they’re all going to be part of that.Indeed, with relaxed minimum requirements on buttons and other features, Android 3 may ultimately find itself on more types of hardware than earlier versions did. And unlike previous versions, you can expect to see official Google-branded apps like GMail, Maps, and the Android Market approved for use on more of those devices.Existing apps will work on Android 3, but the developer can take steps to make the user interface fit in with the new design. These steps range from a simple 5 minute tweak to a more significant redesign.The first step is to update your AndroidManifest.xml file to add a line like this: lt;uses-sdk android:minSdkVersion="7" android:targetSdkVersion="Honeycomb"/ gt;Specifying targetSdkVersion=”Honeycomb” tells Android to use the new Holographic UI theme instead of the older defaults. Once the new version of Android is finalized and goes into production you will use “10″ instead of “Honeycomb”. Specifying minSdkVersion=”7″ indicates you can run on devices that have Android 2.1 and higher. Currently that’s over 87% of all devices in the field. You can use a lower value if your app supports older versions.Next, you can provide alternative layouts for tablet-sized screens. Android 2.3 and above supports the “xlarge” resource qualifier that is activated for tablets. Let’s say you’re writing a twitter application. On a phone you want the twitter stream to occupy the whole screen, but on a tablet you have room to show the stream side-by-side with embedded pictures or conversations or the list of people you follow. To do that, you would put one layout definition (an XML file) in the res/layout directory, and a different one in the res/layout-xlarge directory.See: Hello, Android! for to learn more about supporting a variety of Android versions, screen resolutions, and API levels in your programs.With the easy stuff out of the way, you can then use the new APIs in Android 3 to extend your app to take advantage of some of the new user interface paradigms. For example, you could use the brand new Fragment class to define reusable panes within your app, and you could use the new android.animation package for animating the properties of Fragments, Views, or anything else. There’s also a new 3D framework called Renderscript that lets you build 3D scenes and write OpenGL shaders in a platform-independent language. Naturally, the more Honeycomb-specific eye candy you add to your app, the harder it will be for you to back-port it to earlier versions of Android. Be sure to test on all the platforms you support, and support only the platforms you test.With careful design your programs can look fabulous on all Android versions, screen sizes, and form factors. So in that sense, Android 3 is an evolutionary release just like Android 1.6 or 2.0 was before it. However, the new tablet focus and APIs could enable new types of apps that we haven’t seen on the platform before. You might choose to take advantage of this opportunity to create revolutionary apps that are optimized specifically for Android 3 on tablets. It’s entirely up to you. p
by Ed Burnette at January 27, 2011 05:53 PM
Created and maintained by the Planet Eclipse Admins.
Hosted by the Eclipse Foundation (Privacy Policy, Terms of Use).