Java Blog

Remote Workspace Preferences Plug-in
Category: Team Development

Description: The Remote Workspace Preferences Plug-in provides functionality to import a Eclipse preference file (EPF) from a remote location accessible by HTTP. Besides that it is able to detect new or unconfigured Eclipse workspaces and a simple variable substitution mechanism allows for localization of the preferences.

Remote Project Properties Plug-in
Category: Team Development

Description: The Remote Project Properties Plug-in provides functionality to configure projects within the workspace using a a very simple, shell script like command file. The so called Eclipse Project Configuration Script (EPCS) files are fetched using a HTTP transfer or from a local source. The commands supported include creation of directories, deletion of directories and files and a file download.

I just spent some time updating the sample projects I provide to help Eclipse RCP developers get started with PDE Build. One of the main reasons for the update was to decouple the product configurations from specific feature versions, and I thought it was worth a post to talk about this.

What’s the problem?

By default, product configurations are hard-wired to specific feature versions. And if you decide to upgrade to a new version of the org.eclipse.rcp feature, for example, then your product configuration will break. You won’t be able to create valid run configurations based on your product and your builds will fail as well.

Luckily, we now get feedback in the Product Configuration Editor informing us that something is amiss.

So what can we do about this? Well one approach is to re-wire your product to the new version of the feature. You can do this by deleting and re-adding the feature, or you can also click the Properties button and modify the feature version manually. But this is a brittle approach, as you need to remember to update your configuration every time a feature version changes.

A better way

It’s now possible to decouple products from feature versions by replacing the feature version numbers with 0.0.0. In the future, a blank feature version will also be interpreted as 0.0.0 but as of Eclipse 3.5.1 the number must be added.

Also, there is a currently a defect in the Product Configuration Editor that results in a feature version entry of 0.0.0 being ignored. Of course, this won’t matter once blank versions are interpreted correctly, but for now it’s a problem. The solution is to open the product configuration file in a text or XML editor and change it manually.

The good news is that you only need to do this once. Your product will now accept the feature versions you supply in your target platform without complaint. Of course if you want to maintain the wiring between products and feature versions, by all means do that. But it’s nice to know we can decouple these pieces if we wish.

Share/Save

Oracle Exadata V2 – mit der FlashFire-Technologie von Sun.

ExploreFS
Category: Tools

Description: The only purpose of this tiny plugin (6K) is to open the folder in the native file manager containing the selected resource. It adds “Open in File System” to the context menu of package explorer, resource navigator and any other view showing files or Java classes. It also finds the containing Jar file for classes. Windows, Mac OS X, and Linux are supported.

RSS View
Category: Tools

Description: RSS View is an RSS/Atom reader whose compact UI is designed to integrate into Eclipse and coexist with your workbench. You have everything at one place. RSS View may also improve your development process by integrating your bug tracker, development forum or wiki directly in your IDE. Features include grouping and filtering news feed items, offline feeds, and several customizations.

FreeMem
Category: Tools

Description: FreeMem is a graphical memory monitor integrated into Eclipse 2.x and 3.0.

Features include:
* Short term memory monitor showing the last minute
* Long term memory monitor showing the last two hours
* Manual and automatic garbage collection
* Graphical memory indicator in the title bar
* Preferences to adjust display and behaviour

This content first appeared on the Eclipse Wiki!

Execution Environments in API Tools

Execution Environments (EE) are a neat concept within OSGi, however, things can become complicated when developing against multiple EEs. When you want to contribute code to Eclipse, chances are that you will be asked to downgrade your code to the lowest possible execution environment.

For example, suppose that you want to contribute a Twitter client to Eclipse, or any other open source platform. If you are already accustomed to the OSGi way of working you would probably want to split your code into several independent bundles (AKA modules or plug-ins). At least you would provide a module named org.eclipse.twitter.core and one called org.eclipse.twitter.ui. To be really useful, it would be the bomb if the core bundle could run on, say, a watch. For watches, and other minimal devices there is a special Java environment which is a subset of Java 1.4 (without regular expressions unfortunately) called Foundation 1.1 or CDC 1.1/Foundation 1.1. There is also a Foundation 1.0 but this is really stone age and hardly not used. From what I know, Eclipse uses the 1.1 as a minimum level.

Your org.eclipse.twitter.ui package would normally not require such a primitive environment, however, if somebody wanted to implement a twitter client on a watch, he or she could at least use your core to handle the difficult stuff.

Specify an Execution environment

Execution Environments for a specific (plug-in) bundle can be specified in the manifest editor. It is generally only necessary to specify the lowest EEs that your bundles require. In the preferences there is also a section Execution Environments in the Java section. Just type “exec” in the preference search box to get the indicated page. This merely states which installed JRE’s are able to provide the required Execution Environment. It is clear that a Java 5 JRE cannot provide a Java 6 Execution Environment. The other way around is possible but that generally provides more than is required and can lead to confusion.

For example, a Java 5 JRE can provide the “split()” method for String but this method is not available in Foundation 1.1. Even if your execution environment was set to CDC 1.1/Foundation 1.1 in your manifest file, this problem would only be detected when it was executed against a Foundation 1.1 JRE.

Setup API Tooling

However, we want Eclipse to guard this and warn us when we try to use illegal (future) methods or classes. In order to set this up, we first have to get the available execution environments from the Eclipse update site. In order to do this, go to the preferences and type ‘API’ in the search box. Then select the “API Errors/Warnings” page. If you open the first section “General” and select “Error” for the “Invalid references …” field, the “Supported Environments” box will be accessible and you can click on the provided link.

Clicking this link will open the familiar P2 installer dialog. Select the proper download site and then download all available Execution Environments.

Make sure to switch on the required Errors and/or Warnings. There are convenient buttons available to flip all switches at once to the desired state. Be restrictive if you are serious about your execution environment.

Activating the Project for API tooling

The last thing to do is to activate the project for API tooling, only setting the Execution Environment in the Manifest file will not do anything. Before a project is created, you are able to specify if the API Tooling must be activated by checking the “Enable API Analysis” field.

This will set a project nature that in turn provides special builder classes to check for EE JRE incompatibilities (amongst other things.) If you have forgotten to check this box then you can also do it later. Right-click your plug-in project and select the “API Tooling Setup” option from the PDE Menu in the context menu. This will apply the nature after the project was already created.

A dialog box will appear to warn you that an API baseline is not set. You can ignore this if you only want to use the API tooling to specify the Execution Environment.

Checking your Source

Surely, some of your sources will be showing the red cross. Open a source. Press CTRL+. (dot) to go to the first error and hoover to find the cause. This could look something like this:

Many thanks to the PDE team for this great tool!

I think Adobe is a pretty amazing company and it seems they do a good job re-inventing themselves and this latest announcement is not very shocking but tells you something a about how they work.  Getting Adobe Flash on the iPhone is in my opinion huge because now you don’t need a Mac to do iPhone development and if you are already a Flash developer your apps will “just work”.  This will be huge for games I am sure but on the business side I am seeing more and more companies doing Flash development and this might be a huge on ramp for their “ubiquitous platform“.

Adobe circumvents Apple to bring Flash apps to iPhone

Adobe is trying to make Flash a ubiquitous platform that developers can write to across PCs, netbooks, phones, and TV set-top boxes. It announced Monday that a beta of its FlashPlayer 10.1 software will be available later this year for desktops and for Windows Mobile and Palm webOS devices, with support for Symbian and Google Android phones coming next year.

technorati tags: Adobe, iPhone

There are 4 weeks left in the fall Eclipse training series. Classes on Eclipse Rich Client Platform
(RCP), Equinox & OSGi and Modeling are being offered until December 4. You can learn practical
techniques and tips in a classroom setting or online from Eclipse experts.

See
the schedule for a complete list of classes and course descriptions.

Richard Stallman, Vordenker der Free Software Foundation, wirft Microsofts neuer Codeplex Foundation vor, den Aspekt der Freiheit von freier und Open-Source-Software zu ignorieren. Sam Ramji, Präsident der Stiftung, hat unterdessen deren Ziele näher erläutert.

Richard Stallman, Vordenker der Free Software Foundation, wirft Microsofts neuer Codeplex Foundation vor, den Aspekt der Freiheit von freier und Open-Source-Software zu ignorieren. Sam Ramji, Präsident der Stiftung, hat unterdessen deren Ziele näher erläutert.

Linux 2.6.31.2 bringt nicht nur kleinere Bugfixes, sondern auch einige ausgewählte größere Änderungen. Die X.org-Hacker passen ihre Entwicklungsstrategie an und wollen langfristig einige Treiber wieder mit dem Code des X-Servers zusammenführen.

Linux 2.6.31.2 bringt nicht nur kleinere Bugfixes, sondern auch einige ausgewählte größere Änderungen. Die X.org-Hacker passen ihre Entwicklungsstrategie an und wollen langfristig einige Treiber wieder mit dem Code des X-Servers zusammenführen.

EclipseNSIS
Category: Build and Deploy

Description: EclipseNSIS is a plugin for the Eclipse platform which enables editing, compiling and testing Nullsoft Installer (NSIS) scripts. It also includes the EclipseNSIS InstallOptions Editor plugin, which enables editing of InstallOptions scripts.

EclipseNSIS Utilities
Category: Other

Description: Eclipse plugins for:
a) generating JNI header files.
b) Digitally signing & verifying JAR files.

Der US-amerikanische Spezialist für quelloffene Business Intelligence kauft die Analyse-Software Clearview von LucidEra. Sie soll als Frontend Pentahos eigenes Analyse-Angebot ergänzen.

Der US-amerikanische Spezialist für quelloffene Business Intelligence kauft die Analyse-Software Clearview von LucidEra. Sie soll als Frontend Pentahos eigenes Analyse-Angebot ergänzen.

On Thursday this week (October 8/2009), I’m presenting Mylyn at the FOSSLC Eclipse Bootcamp in Ottawa. Doug Schaefer will be presenting “Eclipse CDT and developing for Android”, and Boris Bokowski will be introducing e4.

I wish this was happening after Eclipse Summit Europe. If it were after the Summit, I could apply some of the wisdom from Steffen Pingel’s Effective Mylyn talk to my own.

See you all at the Bootcamp and/or Eclipse Summit Europe

Durch das nicht rechtzeitige Einreichen erforderlicher Unterlagen verliert die Open Source Initiatve, Hüterin der Open-Source-Definition, das Recht, in ihrem Heimatstaat Kalifornien als Unternehmen zu agieren.

Durch das nicht rechtzeitige Einreichen erforderlicher Unterlagen verliert die Open Source Initiatve, Hüterin der Open-Source-Definition, das Recht, in ihrem Heimatstaat Kalifornien als Unternehmen zu agieren.

There is now a new eRCP for Linux Qt release available from eRCP downloads. This release includes bug fixes for the eSWT port on Qt. Rest of the eRCP plugins have no changes. You can see a list of changes from release notes.

As always we would like your contributions, the easiest way to contribute is to download the release, test and report bugs. For those that would like to get their hands into the water, we are posting bugs with “helpwanted” keyword to bugzilla.  If you would like to help with implementing the full SWT on Qt this bug may be interesting for you as it is the first step towards the SWT implementation.

Mit dem neuen XenDesktop 4 sollen virtualisierte Desktops so einfach und flexibel wie nie zuvor werden, verspricht Citrix: Die ab Mitte November verfügbare Software soll verschiedene Virtualisisierungsansätze unterstützten.

With the work I was doing for e4 builds I’ve had the opportunity to set up a PDE build and test environment. So I thought I would setup the Platform UI automated tests to run in a continuous build cycle on a machine in the lab.

I think it’s interesting because:

1. The tests need to run against the latest I build for that week
2. I need to patch 2 features to install my plugins from HEAD. I just followed Andrew’s instructions.
3. I wanted to use p2 to configure the tests, not the Automated Test Framework

As there’s no real packaging or reuse involved, I just set up 3 features to drive the build. My 2 patch features, which include all of the Platform UI plugins that need to be replaced in org.eclipse.rcp and org.eclipse.platform. And my test feature, which includes the 2 patch feature, all of the Platform UI test plugins that contain my automated tests, and the automated test framework plugins:

• org.eclipse.core.tests.harness
• org.eclipse.test.performance
• org.eclipse.test
• org.eclipse.ant.optional.junit

Setting up PDE build involves copying the headless build templates (build.properties, customTargets.xml) and setting the parameters to match your build environment. Then creating a map project that’s pointing to the correct features/plugins, and away you go.

For continuous builds you tend to want to build from HEAD. The best way (especially if you have a real map that’s is regularly tagged for something else) is to set to properties:

   forceContextQualifier=v${buildId}   fetchTag=HEAD

That way you don’t end up with a lot of plugins that look like com.example.plugin_HEAD

I also want to generate a p2 repo so I can consume my build easily. That’s the standard set of p2 properties at the bottom of the build.properties file.

Once that’s up (and a few tweaks to the customTargets.xml to use the latest I-build I will provide) and then you can build with the org.eclipse.ant.core.antRunner application.

Now I want to use p2 to run my automated tests. First I had to use XSLT to fix the content.xml and relax the feature patch version ranges (feature patches will target a very specific feature qualifier combination). There’s a potential p2 fix in the works, but simple XSL will do for now.

I’m running the automated tests in my postBuild, with modified code I swiped from the Eclipse SDK automated test framework. The difference is that instead of having to generate a test.properties with the correct test plugin to test plugin version mapping and trying to unzip the build plugins into the eclipse test instance, the setup to run the tests now involve:

1. unzip the eclipse test instance
2. Call the director to install the plugin under test, the support plugins, and the patch features
3. call the plugin’s test.xml

It manages all of the version numbers and dependencies for free, so your list of IUs looks like:

-installIUs ${testPlugin}, org.eclipse.test, org.eclipse.ant.optional.junit, org.eclipse.ui.test.platform.patch.feature.group, org.eclipse.ui.test.rcp.patch.feature.group

And now I have my headless automated test environment The relevant build files and map files can all be found in CVS.

• :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse
• platform-incubator/ui/org.eclipse.ui.automated.build/org.eclipse.ui.releng

There are a lot of opportunities for improvement in this environment (continually updating the build target from http://download.eclipse.org/eclipse/updates/3.6-I-builds for example) but this is enough to get me started.

PW