maandag 21 december 2009

Am I Fragment or am I Bundle

Sometimes you want to know if there are fragments attached to a bundle so you can perform some logic. Eclipse's Platform class is able to help you in this area because it lets you get a list of BundleDescription objects like this:

BundleDescription[] binfos = Platform.getPlatformAdmin().getState(false).getBundles();
for (BundleDescription bundleDescription : binfos) {
if(bundleDescription.getHost() != null)
System.out.println("I am Fragment");
}

maandag 16 november 2009

OSGi: GESUNDHEIT!

This blog is about the upcoming OSGi course run by Neil Bartlett. If you are writing moderate to large size Java applications and you have heard about OSGi but are still a little puzzled about what it does: OSGi is the biggest thing that happened to Java this century. Here are three reasons why this is the case:

1. OSGi enforces modularity
Making systems modular feels good to every engineer. It is just a logical thing to do when systems grow. We define and design modules in our systems. But once implemented, they cannot be taken out or replaced by a better version because they get entangled so quickly. When coding OSGi style, this will not happen. Why? Read on.

2. OSGi defines module boundaries
One reason modularity is enforced is because you define a clear entrance point in your modules which is the interface to the rest of your system. No unclear API due to many public classes, but a well defined set of visible classes that were meant to be API. The rest is hidden, public or not public. Why is this handy?

3. OSGi helps you manage complexity.
Once you can see your modules as giant blocks of LEGO(tm) (having a clear interface) you can think about what the weak blocks are and how they can be replaced or hardened. Do all your work inside the module but be faithful to the interfaces with the outside world. This is how they build Skyscrapers.

Although it sounds to good to be true, true it still is. And even though OSGi sounds like a sneeze, it is all about the GESUNDHEIT of your applications.

We host an OSGi course in December. There are a few places left. Neil Bartlett will be your teacher. By the way, Neil did write the book, a free book and the eye opening first chapter is right here.

Apart from the course we will take you on a Amsterdam by Night tour where you will get a good, but not too good, impression of the unique Amsterdam culture. It is about 30 minutes drive from the training location to the center of Amsterdam.

See you there!


dinsdag 6 oktober 2009

Eclipse API tools: Execution Environments

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

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.

Java Execution Environments Preference Page


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.

Enable the Supported Environments dialog


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

Downloading the 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.

Result

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.

Activate API Tooling

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.

Activate API Tooling

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.

API Tooling warning

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:

API Tooling in Action



Many thanks to the PDE team for this great tool!

woensdag 19 augustus 2009

Running Equinox OSGi and ECF on the System i - Part 2

In the previous installment of this series I have demonstrated what it takes to run OSGi on the AS/400 (or System i as it is called today.)

Goal
In this part we take the OSGi installation one step further by adding additional bundles to the initial installation. A bundle is OSGi slang for a group of Java classes that together perform certain tasks. They are also called modules or plug-ins (because of their plug and play nature).

Remote Services
As I mentioned earlier, our company is in the process of creating a multiplatform SCM for which we need a Multiplatform Communication Layer. Multiplatform can be mapped to Java and Communication Layer translates to the Eclipse Communication Framework, ECF. Since we have already decided to use the OSGi technology as the runtime container, we were also looking for a OSGi defined solution. As you might know, OSGi only provides specifications. It is up to others, like the people from Eclipse and Apache, to write an implementation. One of the new specifications in the upcoming OSGi release is referred to as RFC 119. It describes how an OSGi service should be addressed remotely.

Remote Services is important to us because we have to sometimes manage several hunderds end-nodes. Beeing able to do so in standard OSGi makes us free from the choice of using one specific remoting solution. The RFC 119 technology enables us to choose from different implementations and we have tried both the Apache and the Eclipse implementation.

Cleanup the OSGi installation
If you have followed the previous article, you will notice that there are a lot of bundles in the plugins directory. For our current purpose we don't need all of them and we also want to be as clean as possible. So we are going to move all the unused bundles to a special directory called "Equinox Bundles" we can get to this directory if we need another bundle later. Create a directory with the name "Equinox Bundles" in the /QOpenSys/Equinox directory and move all the bundles in the "plugins" directory into this directory. Now copy back the three jars from the "Equinox Bundles" directory that start with:
  • org.eclipse.equinox.common
  • org.eclipse.osgi
  • org.eclipse.update.configurator
and are followed by a version number and a build identifier.

Setup the configuration.ini
OSGi is configured using the config.ini file in the installation directories 'configuration' directory. OSGi already created this directory for you after the first launch. If it is not there, please see the first article and run the framework.

Now we are going to create the config.ini file with the following content:

osgi.bundles=org.eclipse.equinox.common@2:start, org.eclipse.update.configurator@3:start
eclipse.ignoreApp=true
osgi.install.area=file:/Qopensys/Equinox/plugins/
osgi.console=667
osgi.noShutdown=true

Line 1 instructs the OSGi framework to first start the common bundle and then the configurator bundle. The configurator bundel will automaticall
y install all plugins that are located in the plugins directory of the install directory. In the next step we will put all of our non-framework bundles in that directory.

Line 4 will listen at the TCP/IP port 667 with a telnet server. You can use putty or any other client to telnet to port 667 of this machine. It will give you the console and enables you to run the OSGi framework in a batch job and still be able to control it. Mind you that many OSGi installations happily run without a console or are controlled through other means (e.g. a controlling bundle).

Running as a Batch job
To run the OSGi framework as a batch job start the following command (adapted to the id of your download)

SBMJOB CMD(JAVA CLASS('/QOpenSys/Equinox/plugins/org.eclipse.osgi_3.5.0.v20090520.jar')) JOB(OSGI)

Now fire up your favourite telnet client and try to access port 667. Keep in mind that you can only connect one session at a time.

Now type the "ss" command to show that the framework is running and indeed all our bundles are active.









The exit command will stop the framework and exit. The disconnect command will terminate the telnet session but will leave the framework running.


Setup ECF
Since we are Eclipse junkies we setup our distribution server with the ECF software from Eclipse. So download the ECF SDK. If this link is broken then just go to the Eclipse site and navigate to the ECF SDK and get the zip. Then drop all the bundles from this zip into the '/QOpenSys/Equinox/plugins/plugins' directory. That is correct, two plugins directories.

The reason for this is the org.eclipse.osgi.configurator bundle. It will install all bundles that are found in the plugins directory for us so we don't have to do that ourselves. Since we have installed OSGi in the /QOpenSys/Equinox/plugins directory, we have two directories with this name.











Now stop the framework and submit the job again. Telnet to port 667 and try the "ss" command. This time you will see a lot more. You can filter the list to show only the active bundles by using "ss -s active"

The Next Time
The next time we will create two plugins. One will consume the remote service that the other will provide.

Thank you for your feedback


vrijdag 31 juli 2009

Running Equinox on the System i - Part 1


For our next version of TD/OMS, which is our System i based Software Change Management System, we are moving to OSGi. Since a large part of the processing involves the management of the local System i file system we also need to setup OSGi on this machine.

Okay so the first thing to do is to determine which OSGi implementation to install. Since we are an Eclipse foundation member the first thing to try is the Eclipse implementation of OSGi called Equinox. Equinox has its own page at http://www.eclipse.org/equinox and there is a quick start guide.

The quick start guide instructs us to download Equinox from the download site and sure enough there is a 25 mb drop. After downloading the contents of the zip we can safely say that there is too much in this file but we will worry about that later.

Installing Equinox on the AS/400
I have arranged network access to the IFS so the first thing to do is determine a location. For this I have picked the QOpenSys file system which I always use for long filename and case sensitive related stuff. In the QOpenSys file system I create an Equinox directory and then I copy the plugins directory from the drop into this directory.

According to the getting started guide I would now be able to run equinox with the following command. java -jar org.eclipse.osgi_3.2.0.jar -console

On the System i and translated to the correct jar in the plugins directory (yes you have to look that up yourself) this looks like this:

JAVA CLASS('/QOpenSys/Equinox/plugins/org.eclipse.osgi_3.5.0.v20090520.jar') PARM('-console')

The 5250 java console pops up and after a while the message "Attaching Java program to /QOpenSys/Equinox/plugins/org.eclipse.osgi_3.5.0.v20090520.jar." appears. This is the indication that the jar file was found and that the System i is now compiling all class files to local digestable classes.

And sure enough, after a short while we see the OSGi console. To check all the installed bundles we enter the command "ss" and there, in all its glory, is the org.eclipse.osgi bundle.

I would call this a completely painless operation.

In the next part I will try to install ECF and some homegrown bundles






woensdag 24 juni 2009

Funny History Lesson About SWT (+ Jigsaw)

Hi,

I have found a reference post to an "inside story" on SWT. Quite funny. Maybe you already know it but for others it will be new. What is also funny is that it contains a reference to a project called, yes, "Jigsaw". It appears that all projects with that name are doomed to go under, which some might call good news. :-D

dinsdag 9 juni 2009

The Aware Workbench (1) (win a T-Shirt)

Wouldn't it be great if the workbench would know if the stack trace you are seeing was already reported as a bug. Or if you could just ask a question and it would notify you if the answer arrived. Maybe you are in need of professional services: the workbench just opens a map and shows you where you can find them in your location. How about a workbench where you can just chat with peers and experts or let your workbench twitter your success:

wimjongman just let me, his workbench, create the com.remainsoftware.salvo.application product for 5 target platforms

This is currently beeing discussed in bug 279383 please join in. BTW, You can win a T-shirt (not from Eclipse) if you point out the thing the average workbench can already do.

donderdag 4 juni 2009

is Eclipse still Rock & Roll?

Gezellig

Tomorrow evening (thursday, june 11) there is the Dutch Eclipse Democamp. Almost 30 people enrolled, including the famous Marcel Offermans, member of the PMC of Apache Felix and the Dutch Oracle on Open Source legal aspects, Arnoud Engelfriet.

Martin Taal, the EMFT Teneo project lead will be present and Jos Warmer, lead of the mod4j project, is presenting mod4j.

If you have something to share or just want to watch and talk about the Greater Eclipse, this evening is for you. There will be an interesting mix of topics, Please check out the current Agenda and enroll. You can also mail yuri.kok@industrial-TSI.com and he will put you on the list.

Drinks and beverages are on us and the Eclipse Foundation. It is going to be interesting and

Newsreader update

V0.4.0 of the newsreader is available @ http://wiki.eclipse.org/newsreader. I have just added colouring so that you can see the status of a discussion (1:my articles, 2:new reply to participating thread, 3:participating thread):






Download and help me get this project on the road.

zaterdag 30 mei 2009

Salvo, the Eclipse based Newsreader

Version 0.2 for windows of the Salvo newsreader is available on http://wiki.eclipse.org/Newsreader. It has only the foundation of a newsreader but we have started to work on the fun stuff. If you want to give it a spin, please do.

vrijdag 29 mei 2009

Community is a superclass of Economy

The big scope

My personal "frustration" with Eclipse is that it is a technology focussed community and although I am a techie avant la lettre (yes I did program assembly on the Zilog Z80) I am also a business owner concerned to put food on the plates of my employees (I pause for a second so you can wipe your tears).

I want to bring Eclipse consumers and Eclipse providers together inside the Eclipse community so that we can create an Economy. With this I mean that there must be a place inside Eclipse where consumers can contact providers but providers can also make themselves visible for consumers and therefore Eclipse must know their consumers.

The first step

Since Eclipse is a community and all efforts arise from this community, there is no use barking against the Mighty Moon (MM pun intended) to make this happen. Instead I feel I/we have to do something.

I would like a "Community", "Collaboration" or "Community Collaboration" or "Community and Social Collaboration" top level project. In this project we place tools like Mylyn, the ECF collaboration projects and others (like a newsreader, read on) as a start and integrate this with the base Eclipse download.

The next steps

The next steps are to really focus on creating an Eclipse Economy after we have established the Eclipse Community; Community is a superclass of Economy. There are a lot of companies paying for Eclipse membership. We are a "$5000 a year" member.

Call us "the middle class".

Now that the times are hard, this middle class want to see some direct effect of this membership before we cancel and just take Eclipse like the rest of the world. My believe is that companies like ours must form the bigger part of the income of the Eclipse foundation just like the middle class is the base of any countries economy.

All bla bla?

Mostly, but I don't want to just talk about this. I am currently working an a newsreader project to give the community a voice from within the Eclipse workbench (see below if you want to give this Alpha project a spin).

The next project I want to work on is a (Google) map which is accessible from the Eclipse Help menu that shows where you can get Eclipse services in your region. The entries in the map are the companies that pay for Eclipse (like Remain, Industrial-TSI, Weigle-Wilczek, IBM and others :-).

I thank Bjorn Freeman-Benson, Eric Rizzo and Wayne Beaton for support and inspiration.

The newsreader project

Here is the RCP application of the newsreader project (windows). Remember, it is still Alpha software. You can read and reply but not yet post. This will be fixed in a couple of days.

Follow me on http://twitter.com/wimjongman for last minute info on the newsreader or check the Eclipse wiki for detailled info: http://wiki.eclipse.org/Newsreader


It is pretty simple but here is a five minute instruction without audio:

woensdag 29 april 2009

Getting more out of the Ecosystem (1) - Bugzilla

This is a series of suggestions on how we can grow the Eclipse Ecosystem. Now the economic situation is a bit slower, I get questions about our yearly $5000 contribution. Why don't we just _take_ Eclipse, like the rest of the world.

Who are our users?
I believe that we should know our users. It is great that we know that China is #1 with more than a billion downloads, but who are these guys and how are they using Eclipse? Can we get in contact with them so that we can do business together? No, becasue we don't know who they are.

Does Microsoft know who every Visual Studio user is? No, they do not have a clue (just joking haha, it _is_ a joke to think that Microsoft does not know their users.) Of course they do, our company is one of them and sure we get a lot of spam but every now and then we get some eggs and sausages.

Does Sun know the Netbeans users? I don't know but their download page attempts to reap the low hanging fruit.

A Bugzilla Account is Mandatory
I suggest to only allow downloads after the user has registered for a bugzilla account. In this registration we do like Sun does and ask these users if we may contact them. In Jax Germany I attended one of Wayne Beaton's sessions and he asked a group of about 40 people who had a bugzilla account, about 5 raised their arm. Now Jax Germany is a 1500-dollar-entrance-fee event. Why don't these guys have a bugzilla account? And why is it called a bugzilla account and not an Eclipse account?

With our known users we can do all sorts of things.

  1. Send them information about Eclipse Projects
  2. Send them information about the traning series
  3. Give Marketing information to the Members (us)
  4. Ask if they want to be an Eclipse Member
  5. your input here

People won't mind because they want to be part of Eclipse. They would rather hear from Eclipse than to be left alone. And remember, A bugzilla account is just one click away.

Eclipse Demo Camp in the Netherlands

Demo Camp in the Netherlands
Industrial-TSI will be organizing the third Eclipse Democamp in the Netherlands. We have compiled a little survey so that you can indicate what you want to see. The survey can be found here. 

Get a Bugzilla Account
In addition to this, Dutch Eclipse lovers, you can can submit a short talk about your favourite Eclipse related topic on the Eclipse Democamp Wiki. You need a bugzilla account to change the wiki. The bugzilla account can also be used to respond to bugs or report new ones. All Eclipse users should get one. A bugzilla account is just one click away. 



donderdag 19 maart 2009

The Super Pattern of Order

The Super Pattern of Order

Humans like to order stuff. This is done by putting it somewhere where (we think) we can find it again. We have houses with rooms and closets with drawers. We have pockets, briefcases, safes, bank accounts, wallets, shelves, etcetera. Each location is meant to store something that fits in that location. Socks go in drawers, closets go in rooms and money goes in wallets. 

There is also a place for electronic documents. These locations often have metaphorical names like directory, folder, archive, “zip”, library or cabinet, to name a few.

Enables us to Locate Stuff

To find socks, I got to my closet where I open the drawer that contains my socks.  To find this document, I go to my computer, open my home folder and there it is. To find stuff we need a way to address it. My document can be addressed by three parameters. 1, the computer, 2 the folder and 3 the document name, or, in more abstract terms, the platform, the location and the name.

So that we can Manage it

What we want to do with electronic documents is to move them around. This document for example wants to leave my computer.  And it has, apparently, otherwise you would not be reading this. The reason for moving it around is that I want to get it from the initial location where it was developed to our QA department where it was reviewed to the final location where you found it (to tell you the truth, it did not go through QA).

Just to make Sure

I could just simply type the document, e-mail it to QA and let them forward it to the final place on the location where you found it. This model is based on trust and although I fully trust our QA department (hi guys!) I would want to have some control over the fact that my document completes its lifecycle (i.e. ends on its final destination). 

That we don't Lose it

And then, after I have received lots of comments, I want to maybe change it to mask the fact that I am not a native speaker and replace it on every final location with the new version.


maandag 16 maart 2009

Package naming convention in a mixed Java and OSGi world

The "standard" before OSGi was to move all internal stuff into *internal* packages.

IBM uses the *internal* approach in the ready for rational program:

Requirement: General 2.5
a)      Provide a list of non-public Eclipse interfaces and the methods used by your offering...

This means that IBM exports *internal* packages and asks for a rationale if you use one of its internal classes. This approach enables you to:
  1. point the programmers to the correct way to use the software
         OR 
  2. move the class out of internal and into the official API.
In OSGi, if you do not export a package, the programmer cannot access it. However, this breaks the important aspect that programmers sometimes use your classes in ways you did not envision. So you also export packages that could be interesting and only hide the absolutely non API packages.

However, if you want to use the jar outside of OSGi then there is no way of hiding the absolute non-API packages and also no way of recognizing that the package is off limits. 

Conclusion: there should be a new naming convention providing for three levels of package visibility. 
  1. API,  dom.organization.soandso
  2. Not intended to be API dom.organization.internal.soandso
  3. Absolutely not API dom.organization.private.soandso