All about Java
Glyn Normington (VMware), Steve Powell (VMware)
Abstract:
The Eclipse Virgo project provides a modular open source application server based on OSGi. The project is a donation to the Eclipse foundation of the dm Server open …
Glyn Normington (VMware), Steve Powell (VMware)
Abstract:
The Eclipse Virgo project provides a modular open source application server based on OSGi. The project is a donation to the Eclipse foundation of the dm Server open …
Jeff McAffer (EclipseSource)
Abstract:
With the Eclipse community expanding its offerings in the Runtime space (EclipseRT), many developers are interested in figuring out what this means and how they can leverage EclipseRT …
Event Date: May 20, 2010 10:00 am GMT-8
<!–
–>
OSGi has been in the press a lot lately. Everywhere you turn there is some new product or project adopting the technology. From Eclipse to Apache to Spring. From servers to desktops to embedded. OSGi enables the creation of highly modular, dynamic Java-based systems.
Wondering what it’s all about? Join book author and Equinox OSGi project co-lead Jeff McAffer (equinoxosgi.org) for an introduction to Equinox and OSGi concepts and look at the breadth and depth of technology available in this space.
This mini-course is designed to give you a clear understanding of the essential concepts, facilities and advantages of this key technology. This session will be of use to anyone interested in building flexible systems in Java. It is particularly useful for technical managers and decision makers to help them better understand the overall runtime technology.
Total running time for the course is 2 hours.
delicious | 
digg | 
dzone
<!–
–>
Any Java developer, especially one who works with open-source software, will tell you that being the build monkey is a thankless job. You spend all of your time digging through Ant XML files and pulling down the proper classes and methods from constant…
<!–
–>
Scala and OSGi both aim at very important concerns in software development: ease of use and reduced complexity. Scala operates at the programming language level, and OSGi at the higher level of a module system. Hence it is natural to combine those two to get the best out of both. This is also straightforward, because Scala compiles to “usual” Java bytecode and offers full interoperability with Java. OSGi is agnostic with regard to the programming language, because it works only with the compiled artifacts and the metadata in the bundle manifest. Hence it is time for OSGi on Scala.
The new Eclipse project ScalaModules aims at Scala based OSGi development. The mission of ScalaModules is to employ the power of the Scala programming language to ease OSGi development.
Of course using Scala for OSGi is itself beneficial, because of the great simplifications Scala brings compared to Java. But ScalaModules also makes use of the additional possibilities offered by Scala, mainly the chance to create a Domain Specific Language (DSL). Therefore with ScalaModules your code will be more intuitive and concise or less verbose and less involved compared to Java-based OSGi development.
Join project lead Heiko Seeberger for a look at this new project and what it has to offer.
Total running time will be approximately 1 hour
9:00 am PDT / 12:00 pm EDT / 4:00 pm GMT – Convert to other time zones
Thanks to Adobe for contributing their Adobe Acrobat Connect product to host this webinar.
delicious | digg | dzone
<!–
–>
<!–
–>
The advantages of loose coupling and explicit dependency management are generally accepted and the technologies that provide these characteristics have become more valuable. While modularization of both infrastructure and applications has always been a desirable thing, Java EE applications have traditionally been bound to a full-blown application server. The Enterprise Modules project (nicknamed Gemini) is a new Eclipse project that undertakes to provide a collection of Java EE-based technologies as a suite of independent modules.
In this webinar, we will describe the relationship between Java EE and OSGi, and discuss what the Gemini project is doing in this area. We will detail its relationship to the standards and highlight the role it is playing in implementing a next generation of Java EE architectures. We will go over the various components of the project and show how they can be used by applications and tools alike.
9:00 am PDT / 12:00 pm EDT / 4:00 pm GMT – Convert to other time zones
Total running time will be approximately 1 hour
Thanks to Adobe for contributing their Adobe Acrobat Connect product to host this webinar.
delicious | digg | dzone
<!–
–>
<!–
–>
Scala and OSGi both aim at very important concerns in software development: ease of use and reduced complexity. Scala operates at the programming language level, and OSGi at the higher level of a module system. Hence it is natural to combine those two to get the best out of both. This is also straightforward, because Scala compiles to “usual” Java bytecode and offers full interoperability with Java. OSGi is agnostic with regard to the programming language, because it works only with the compiled artifacts and the metadata in the bundle manifest. Hence it is time for OSGi on Scala.
The new Eclipse project ScalaModules aims at Scala based OSGi development. The mission of ScalaModules is to employ the power of the Scala programming language to ease OSGi development.
Of course using Scala for OSGi is itself beneficial, because of the great simplifications Scala brings compared to Java. But ScalaModules also makes use of the additional possibilities offered by Scala, mainly the chance to create a Domain Specific Language (DSL). Therefore with ScalaModules your code will be more intuitive and concise or less verbose and less involved compared to Java-based OSGi development.
Join project lead Heiko Seeberger for a look at this new project and what it has to offer.
Total running time will be approximately 38:55 minutes
Thanks to Adobe for contributing their Adobe Acrobat Connect product to host this webinar.
delicious | digg | dzone
<!–
–>
After releasing his latest book covering OSGi & Equinox, I took the opportunity to catch up with Jeff McAffer. In this interview we discuss the basics of OSGi, the Equinox implementation, benefits of modularity and some best practices around using Equinox.
OSGi, which is intended to provide modularity for Java, is the focus of efforts afoot at IBM and the Eclipse Foundation, with IBM leveraging OSGi in its application server and Eclipse using it in a new framework for accessing enterprise technology.
With an upcoming feature pack for WebSphere Application Server (WAS) v7, IBM seeks to make it easier to use OSGi.
Siemens Enterprise Communications have been developing telephony switches for the past 100 years, moving to software focussed solutions in the last decade. To bring their technology offerings up to date, Eclipse Equinox was chosen to give them a solid foundation for their OpenScape Unified Communications suite.
<!–
–>
The advantages of loose coupling and explicit dependency management are generally accepted and the technologies that provide these characteristics have become more valuable. While modularization of both infrastructure and applications has always been a desirable thing, Java EE applications have traditionally been bound to a full-blown application server. The Enterprise Modules project (nicknamed Gemini) is a new Eclipse project that undertakes to provide a collection of Java EE-based technologies as a suite of independent modules.
In this webinar, we will describe the relationship between Java EE and OSGi, and discuss what the Gemini project is doing in this area. We will detail its relationship to the standards and highlight the role it is playing in implementing a next generation of Java EE architectures. We will go over the various components of the project and show how they can be used by applications and tools alike.
Total running time 50:00 minutes
Thanks to Adobe for contributing their Adobe Acrobat Connect product to host this webinar.
delicious | digg | dzone
<!–
–>
Adobe Ajax Android Anwendung Apache API C++ Community Developer Eclipse Eclipse Foundation Embedded English Enterprise Entwickler Equinox Galileo Google Handy IBM IDE Individual Java Member Microsoft Mobile Modeling NetBeans News Open …
As I mentioned a while back, Eclipse Helios M5 was made available for Download. There are number of New and Noteworthy features, but one really big feature was omitted from the N&N. The Eclipse provisioning platform, p2, finally has API! Really, go take a look at the code… all those internal.provisional packages are now gone! This was actually a huge milestone for the p2 team, and Pascal did a great job steering us towards the API.
What does this mean to you? Well, if you are building anything on top of p2 you should grab M5 and see how the new API feels. We are going to be pushing hard to finalize the API for M6, so if there is anything missing, speak up now.
John Arthorne even started a Migration guide: http://wiki.eclipse.org/Equinox/p2/Helios_Migration_Guide
We are in the midst of judging the product categories for the Eclipse Community Awards. It turns out we received only two nominations for the EclipseRT Application category. The judges have decided they would like to see more nominees, so we have re-opened nominations in this category until February 17 at 5pmET.
This is a new category for the Eclipse Awards so some clarification might be in order. If you are building an internal application, commercial product or open source project that uses any of the EclipseRT technology you can send in a nomination. For example, if you have built a killer web application using RAP or a great server application using Equinox, Jetty and EclipseLink or a SOA application using Swordfish or your using SMILA or ….
I know there are a lot of applications and products using EclipseRT technology. The nomination process is pretty easy and this is your opportunity to garner the fame and prestige of an Eclipse Community Award winner. Feel free to contact me if you have any questions.
In a previous assignment we had a project more like an intranet application where you manage document, make applications (which flow through a complex 400+ step BPM), integration with a SOA engine, task, inbox, etc… It was a large government project with 500 daily users.
We chose the RAP [RCP], Databinding, EMF, Teneo, hibernate, JTrecache, Equinox[OSGI] project stack. We also have written a simple editor to manipulate EMF model.
I must admit I enjoyed defining my models in ecore. With the help of teneo my DAO consisted only ~100 lines. Since the application security (this is including down to input element levels with hidden/read/write granularity) was so tight we also kept the security definitions in the ecore model.
We kept the database schema definitions along with the ecore classes, which helped BI developers and DB admins to get updates momentarily (In the early phase of the project there were weekly deployments).
I think one of the problems with java world is it has the J2EE definition. 90% times you make a project, you choose the Application server, JPA, Web model etc for the project. But people believe “If it is a commercial / corporate product it’s gotta be J2EE compliant”, which is a big bold and IMHO unnecessary binding. Most of the time, you do not WORE! Not to mention there is the saying “Write Once Debug Everywhere”.
Lately application server vendors started adopting OSGI and we’ll see where this will go. But to be honest (this might require a correction) without using equinox, you cannot use much of the eclipse technologies where the base plugins require definitions via extension points. e4 with the new dependency injection stuff may make this comment deprecated. But with the more and on-the-target adoption of OSGI, we’ll see more eclipse technologies used outside RCP and IDE domain.
On the project I mentioned, people were like ‘Are you crazy you are taking way more risks, how are you gonna get support’, well, we used the SOA engine and DB of one of the largest provider provider, we have a support ticket still open for 6 months, where I had over 20 interactions with RAP, Teneo, EMF team all resolved within hours to days. Imagine if we were using the application server from that vendor.
In the end, the project was a big success and a breakthrough not in the country but at the global level. So I think developing enterprise application doesn’t mean you gotta go JavaEE. Putting together your own OSGI stack is much better. Plus while developing, you will get the joy of restarting the application in a matter of seconds rather then in minutes in comparison to application servers.
The RAP team just announced the availability of RAP 1.3 M5!
If you’re interested in single-sourcing Eclipse-based applications, please give it a try.
In the 1.3 M5 release, the RAP team added more SWT API to make single sourcing existing applications easier:
Composite#layout( Control[], int )MouseEvent#stateMaskWidget#reskin( int ) and SWT.Skin eventImageDataImageLoaderImageLoaderEventThe team also added IApplication support which simply translates into one less extension point you have to use to create a RAP application. In the past, RAP had its own entrypoint extension point which performed a similar role to what the application support does in Equinox already. This should make RAP even easier for RCP developers to get into.
RAP is also taking advantage of the Equinox extension registry is able to handle multiple locales.
So please give RAP a try if you’re interested in bringing your RCP application to the web.
Let me write a quick response to Elias’ thought-provoking post. I hope there will be other (and not so quick) responses as well – it is important to step back every now and then to assess whether we are going in the right direction. But for now, I didn’t want to let the issues he raises without an answer from the e4 team. The question for me is, how can we turn e4 into a juicy and sweet lemon? 
getViewSite().getActionBars().getStatusLineManager().setMessage(msg);
In e4 this should be:
@Inject
IStatusLineManager statusLine;
...
statusLine.setMessage(msg);
2) I want to get the selected resources:
ArrayList list = new ArrayList();if (selection instanceof IStructuredSelection) { IStructuredSelection ssel = (IStructuredSelection) selection; for (Iterator i = ssel.iterator(); i.hasNext();) { Object o = i.next(); IResource resource = null; if (o instanceof IResource) { resource = (IResource) o; } else { if (o instanceof IAdaptable) { resource = (IResource) ((IAdaptable) o) .getAdapter(IResource.class); } } if (resource != null) { list.add(resource); } }}return new StructuredSelection(list);
I’m not sure how we handle multi-selection in e4, but this should be something
like:
@Injectpublic void setSelection(@Named("selection") List<IResource> selection) {selectedResources = selection;}
3) I want to associate a help context with my control
getSite().getWorkbenchWindow().getWorkbench().getHelpSystem().setHelp( viewer.getControl(), getHelpContextId());
In e4 this should be something like:
@Inject
IWorkbenchHelpSystem helpSystem;
...
helpSystem.setHelp(viewer.getControl(), getHelpContextId());
The end result is simpler code, but it also removes a mass of assumptions that
the client previously had to make, about what their containment structure
looked like and where specific services came from. I think we sometimes take
for granted how difficult it can be for clients in 3.x to figure out where to
get particular service from.
Having said all that, we have probably gone too far down the
“non-specification” route in e4. I think it is essential that we provide
interfaces containing specification of things clients must implement (e.g., you
need a doSave() method for parts that are to be used as editors). We can make
the interface optional if we want, but there has to be somewhere where we
specify the behavior expected/required for clients. To me this specification of
expected behavior for clients is orthogonal to service injection so I hope that
we can have both.
Like the title already says the latest nightly build comes with 2 amazing features one already part of the code base since a long time (XPath to traverse the UI-DOM) the second one just hit SVN (plugable model-item mapping). I’m going to discuss them in short in this blog posting.
You probably ask yourself. What’s this and why should I care. To understand the problem you must know how the current JFace-Viewers are working internally and which problems this can cause.
JFace-Viewers store strong Java-References between the domain model and the SWT-Item using TableItem#setData(Object)/TreeItem#setData(Object) and additionally if you turn on hashlookup (to speed up setting of selections, …) in an internal HashTable.
The problem with this is that your domain model stays resident in memory as long as the TableItem exists even if no one really needs it until you e.g. want to update the table-item. This implementation detail of current JFace-Viewers makes the use of CDO in UI less ideal because CDO can’t apply it’s clever memory management because your UI code holds strong references into your domain-object graph.
One can overcome this problem in JFace-Viewer world as well by writing some clever Content- and LabelProviders (The implementation is also available from our repository but not part of a build yet) but in my opinion not ideal from a users point of view. Moreover I think a viewer framework should have the possibility to plug-in “your” mapping strategy (e.g. provided by the domain-technoloy project you are using) according to the use case.
That’s why I decided that this feature has to be part of the core UFaceKit-Viewer-Framework and the support of it has just hit the SVN-Repository and is part of my shining new nightly athena build.
/*******************************************************************************
* Copyright (c) 2010, BestSolution.at and others
* All rights reserved. This program and the accompanying materials
* are made available under the terms of the Eclipse Public License v1.0
* which accompanies this distribution, and is available at
* http://www.eclipse.org/legal/epl-v10.html
*
* Contributors:
* Tom Schindl <tom.schindl@bestsolution.at> - Initial API and implementation
*******************************************************************************/
package org.eclipse.ufacekit.ui.jface.cdo.viewers;
import java.util.Collection;
import java.util.Collections;
import java.util.HashMap;
import java.util.Map;
import org.eclipse.emf.cdo.CDOObject;
import org.eclipse.emf.cdo.common.id.CDOID;
import org.eclipse.emf.cdo.view.CDOView;
import org.eclipse.ufacekit.ui.jface.viewers.Viewer;
import org.eclipse.ufacekit.ui.jface.viewers.mapping.AbstractTableItemModelMapping;
public class CdoModelTableItemMapping<ModelElement extends CDOObject,Item extends org.eclipse.swt.widgets.Item> extends AbstractTableItemModelMapping<ModelElement, Item> {
private CDOView view;
private Map<CDOID, Item> map;
public CdoModelTableItemMapping( CDOView view, Viewer<ModelElement, ?> viewer) {
super(viewer);
this.view = view;
this.map = new HashMap<CDOID, Item>();
}
@Override
public void associate(ModelElement model, Item item) {
if (map.containsKey(model.cdoID())) {
throw new IllegalStateException("This mapping only supports one instance of a model element");
}
item.setData(model.cdoID());
map.put(model.cdoID(), item);
}
@Override
public void disassociate(Item item) {
map.remove(item.getData());
item.setData(null);
}
@Override
public void disassociateAll() {
map.clear();
}
@SuppressWarnings("unchecked")
@Override
public ModelElement lookup(Item item) {
return (ModelElement) view.getObject( (CDOID)item.getData() );
}
@Override
public Collection<Item> lookup(ModelElement element) {
Item item = (Item) map.get(element);
if( item != null ) {
return Collections.singleton(item);
}
return Collections.emptyList();
}
}
This implementation is completely untested but I think you should get the point because we are not restoring the domain object but look it up from our local CDOView we can once more rely on CDOs clever memory management. Nice isn’t it?
This feature is part of UFaceKit sources since day one in the SVN-Repository but I added it not into the first nightly builds. I think the XPath support for UIs is a fairly unique feature of UFaceKit and the reflective API makes it extremly easy to implement it operations like e.g. applying changes to a many widgets.
package testproject;
import java.util.Iterator;
import org.eclipse.core.runtime.IStatus;
import org.eclipse.core.runtime.Status;
import org.eclipse.equinox.app.IApplication;
import org.eclipse.equinox.app.IApplicationContext;
import org.eclipse.ufacekit.core.xpath.common.XPathContext;
import org.eclipse.ufacekit.core.xpath.common.XPathContextFactory;
import org.eclipse.ufacekit.ui.core.UIDesktop;
import org.eclipse.ufacekit.ui.core.UIFactory;
import org.eclipse.ufacekit.ui.core.UIRunnable;
import org.eclipse.ufacekit.ui.core.UIWidget;
import org.eclipse.ufacekit.ui.core.controls.UIApplicationWindow;
import org.eclipse.ufacekit.ui.core.controls.UIButton;
import org.eclipse.ufacekit.ui.core.controls.UIComposite;
import org.eclipse.ufacekit.ui.core.controls.UIInputField;
import org.eclipse.ufacekit.ui.core.controls.UILabel;
import org.eclipse.ufacekit.ui.core.controls.UIApplicationWindow.ApplicationWindowUIInfo;
import org.eclipse.ufacekit.ui.core.controls.util.Rectangle;
import org.eclipse.ufacekit.ui.core.form.UIGridFormBuilder;
import org.eclipse.ufacekit.ui.core.layouts.GridLayoutData;
import org.eclipse.ufacekit.ui.core.layouts.UIFillLayout;
import org.eclipse.ufacekit.ui.core.layouts.GridLayoutData.Alignment;
import org.eclipse.ufacekit.ui.core.xpath.UFacekitXPathContextFactory;
import org.eclipse.ufacekit.ui.jface.core.JFaceFactory;
import org.eclipse.ufacekit.ui.uform.UBeanForm;
public class Application implements IApplication {
public Object start(IApplicationContext context) throws Exception {
JFaceFactory factory = new JFaceFactory();
final UIDesktop desktop = factory.newDesktop();
desktop.runWithDefaultRealm(new UIRunnable<UIDesktop>() {
@Override
protected IStatus run(UIDesktop arg0) {
createUI(arg0);
return Status.OK_STATUS;
}
});
desktop.run();
return IApplication.EXIT_OK;
}
private void createUI(UIDesktop d) {
UIFactory<?> f = d.getFactory();
UIFillLayout l = f.newFillLayout();
final UIApplicationWindow window = f.newApplicationWindow(d, new ApplicationWindowUIInfo(l));
window.setText("UFaceKit - Hello World");
UIComposite comp = f.newComposite(window, new UIComposite.CompositeUIInfo(null, f.newGridLayout(1)));
UILabel label = f.newLabel(comp, new UILabel.LabelUIInfo(GridLayoutData.fillHorizontalData()));
label.setText("Form Example");
UBeanForm form = new UBeanForm(f);
UIGridFormBuilder builder = UIGridFormBuilder.newInstance(comp, GridLayoutData.fillHorizontalData(), form);
builder.newLabel("Firstname");
builder.newInputField(UIInputField.InputFieldBindingInfo.newTextFieldInfo(form.detailValue(Person.FIRSTNAME, String.class)) );
builder.newLabel("Surname");
builder.newInputField(UIInputField.InputFieldBindingInfo.newTextFieldInfo(form.detailValue(Person.SURNAME, String.class)) );
UIButton button = f.newButton(comp, new UIButton.ButtonUIInfo(new GridLayoutData(Alignment.END, Alignment.DEFAULT)));
button.setText("Save");
button.setActionRunnable(new UIRunnable<UIButton>() {
@Override
protected IStatus run(UIButton b) {
XPathContextFactory<UIWidget> factory = UFacekitXPathContextFactory.newInstance();
XPathContext context = factory.newContext(b.getParent());
Iterator<?> iterator = context.iterate("UIComposite/UIInputField");
boolean flag = true;
while( iterator.hasNext() ) {
UIInputField field = (UIInputField) iterator.next();
if( field.getText().equals("") ) {
flag = false;
field.getStyle().setBackground("#ff0000");
} else {
field.getStyle().setBackgroundColor(null);
}
}
if( ! flag ) {
b.getDesktop().showErrorDialog(
b.getWindow(),
"Validation Error",
"Required fields are marked read",
new Status(IStatus.ERROR, Activator.PLUGIN_ID, ""),
null );
}
return Status.OK_STATUS;
}
});
window.open();
window.setBounds(new Rectangle(500, 400, 400, 250));
}
public void stop() {
// nothing to do
}
}
This creates an UI like this:
Time flies, it is more than 3 years ago that Bjorn Freeman-Benson, BJ Hargrave, and me sat down after the 2006 conference to discuss the possibilities to organize an OSGi DevCon in conjunction with EclipseCon. Today I am proud to announce the 4th OSGi DevCon in Santa Clara, March 22-25. The program is, as usual, staggering. It always impresses me how many people are willing to contribute to EclipseCon/OSGi DevCon. Overall there were more than 350 submissions and about 60 of those were for OSGi DevCon. Picking the most interesting program was even harder than previous years because there is less space; we therefore have less time for OSGi DevCon. However, the resulting program is probably of even higher quality.
First I would like to draw your attention to the fact that we will officially publish the OSGi Enterprise Specification during EclipseCon. The OSGi Alliance will host a BOF on Monday night. One of the co-chairs of the OSGi Enterprise Expert Group, Tim Diekmann, will give a presentation during this BOF of what is in this specification and why it is ground breaking.
We have three tutorials. The first tutorial is from the people that wrote the OSGi and Equinox: Creating Highly Modular Java Systems book. You will get a feel for Toast telematics! See Working with OSGi: The stuff you need to know.
The next tutorial is from Kirk Knoernschild and Neil Bartlett, both very experienced developers and excellent writers and presenters. This tutorial was actually chosen in the EclipseCon Program Commitee top 5. The subject is a very hot topic at the moment: modularity. We all learned the lessons about coupling and cohesion. However, applying those lessons in large developments is still hard. This tutorial will give you theoretical as well as practical insight in modularity and using OSGi to achieve it. See Modular Architecture from Top to Bottom.
The last tutorial is from Karl Pauls and Marcel Offermans. They are the lead developers of the Apache ACE project and have been developing with OSGi forever. Their subject is absolutely core for OSGi although not always that visible. OSGi is not a “Hello World” technology, such examples only work well when the scope is small. The scope of OSGi is, however, large scale technology. Size does matter for OSGi. A consequence of the scale is that systems have a large number of bundles. This number becomes so large that handling these bundles requires automation because it is just too much to do by hand. Karl and Marcel will teach how to manage installations that reach these problems. See Become a Certified Bundle Manager today.
The first long talk is a must for anyone using OSGi. One of the most exciting pieces of work inside the OSGi is the nested framework RFC. Nested frameworks bring back the initial philosophy of OSGi: the bundles are your application. Enterprise servers based on OSGi starting to deploy many applications inside a single framework. In such a constellation, your peer bundles and peer services might no longer be yours. Nested frameworks returns to this model, an application will be installed in a child framework, also called composite bundles. The lead developers of Eclipse Equinox as well as Apache Felix will present the proposed architecture and discuss merits, pitfalls, and problems that still need to be solved. So do not miss Composite Bundles – Isolating Applications in a Collaborative OSGi World.
OSGi is like a sharp knife. When used well, it is extremely useful, when used wrongly it hurts. Chris Aniszczyk, Jeff McAffer, Martin Lippert, and Paul Vanderlei have been working with OSGi for the better part of the noughties and therefore have lots of experiences and the bruises and cuts to prove it. Between them they cover almost any computing aspect that can be used in conjunction with OSGi. Jeff was the driver behind Eclipse’s adoption of OSGi, Chris is the lead developer of PDE, Martin has worked on Aspect Oriented Programming in Eclipse including the weaving issues and is an aficionado of OSGi as well, and Paul brings the experience from the embedded world. A must for anybody that wants to adopt OSGi. See OSGi Best and Worst Practices.
OSGi is at the foundation of RCP, obviously. However, you can use RCP and not see much of OSGi. David Orme has been contracting for J.P. Morgan where they created an internal platform based on RCP. In the last few years they re-architected this platform to take more advantage of OSGi. This is a very good experience report for anybody that has to develop software to be used inside large organizations. See OneBench Reloaded – Pushing the (OSGI) Modularity Story in an Enterprise-wide Rich Client Stack.
Looking at the size of this blog, I do not think I should loose more readers going through each of the 25 mins talks, even though I think they’re more than worth it. I therefore list them here as bullets:
On Valentine’s day the early registration price will end and you’ll have to pay the full amount. So be sure to register as soon as possible to take advantage of this discount. If you’re an OSGi member, you can get an additional discount if you register here with the email address you use on the OSGi members web site.
I am looking forward to see you again in this 4th OSGi DevCon, lets hope it will be the best ever!
The Eclipse RCP became a prominent platform for building client software. One of the delivery mechanisms supported by Eclipse RCP is Sun’s Java Web Start (JWS). Since Galileo Edition some changes has been introduced in the platform. This article provides some hints for creation of the RCP delivered by Java Web Start.
In order to package the RCP I suggest to use feature-based products as described in
a previous article. Following it, you should have a top-level plug-in (also refered as product-defining plug-in) and top-level feature, which is called “wrap”-feature in the context of the Java Web Start.
Before you start with Java Web Start (JWS), export the product and make sure it starts as a standalone application. In doing so, you have to ensure that your references to the plug-ins are correct. One of the way of doing it is to hit the Validate button in the top left of the product editor. 
If the validation is successful, try to export the product. The PDE builder will run and create a distribution. The errors of the compiler/builder/assembler, if any, are reported to files zipped to the logs.zip file in the distribution directory. A prominent error is
Compliance level '1.3' is incompatible with source level '1.6'. A compliance level '1.6' or better is required.
Which actually means that the plug-in classes has not been compiled at all. In order to avoid this error make sure to set the following properties in the build.properties file of the corresponding plug-in:
javacSource=1.3 javacTarget=1.3
After a successful export of the product, just export the top-level feature (the wrap-feature). Make sure to provide the signing information, since JWS requires all resources to be signed. If you are aiming to deliver for different platforms, make sure to define a target platform (Window > Preferences > Plug-in Development > Target Platform) which contains a Delta Pack. A Delta Pack is a set of plug-ins which can be downloaded separately on the
Eclipse Homepage. Also, don’t forget to switch over to the Java Web Start tab of the Feature Export Wizard, activate the checkbox “Create JNLP manifest for the JAR archives” and specify the site URL where the resulting JNLP will be located. Make sure all your features has the provider attribute set, since it is used as the “vendor” inside of the JNLP file, which is a mandatory attribute.
The PDE build will run and create a distribution in the specified directory. Along with the exported JARs in features and plug-ins, the packaging script will generate the JNLP descriptors for every feature. Still, the main JNLP file required for launching the application is missing and has to be provided separately. Here is, how it looks like:
<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="http://localhost/app/" href="app.jnlp">
<information>
<title>application titel</title>
<vendor>provider</vendor>
<offline-allowed/>
</information>
<security>
<all-permissions/>
</security>
<application-desc main-class="org.eclipse.equinox.launcher.WebStartMain">
<argument>-product</argument>
<argument>de.techjava.app.webstart.productid</argument>
<argument>-application</argument>
<argument>de.techjava.app.webstart.appid</argument>
</application-desc>
<resources>
<j2se version="1.4+" ax-heap-size="128m" />
<jar href="plugins/org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar"/>
<extension name="wrap feature" href="features/wrap_feature_1.0.0.jnlp" />
<!-- OSGI setup -->
<property name="osgi.instance.area" value="@user.home/app"/>
<property name="osgi.configuration.area" value="@user.home/app"/>
</resources>
</jnlp>
Important is to specify both, the product id and the applciation id, otherwise you will see the “Application id not found” exception. Of course you can specify
additional options as command-line arguments of the launcher itself. I found it useful to be able to let the OSGi running and then connect to it and query for loaded bundles. You can do it by adding the following arguments:
<argument>-console</argument> <argument>1234</argument> <argument>-noExit</argument>
This will allow to connect via telnet with running OSGi, even after the application finishes.
This is basically it.
This weekend, the Eclipse Foundation released their 3.6M5 of their namesake platform, including the Java IDE for which it has become synonymous. The 3.6 stream, also known as “Helios”, is due to be released in Summer this year; however, the M5 release is likely to be the last feature complete release with the remainder being bug fixes and optimisations.
A welcome feature is the ability for SWT to handle ‘open’ operations. This allows an Eclipse runtime to act as a file association type, such that double-clicking on a file in a user’s desktop will open that file inside Eclipse, without opening a new Eclipse instance. This should allow standalone Eclipse RCP tools to work with standalone files without having to resort to the user manually opening the file in the tool. In addition, Eclipse now has support for “virtual folders” which allow resources to be mapped and organised in a way unrelated to the file system.
The Eclipse platform now also ships with JUnit 3.8 and JUnit 4.7; either can be used with the automated run of tests. For those plugins which don’t explicitly request a version of JUnit, there is a wiki available that discusses the changes needed to allow the tests to resolve. Lastly, the JUnit view allows test runs (recorded with the test runner) to be viewed by dragging the XML test results file onto the view. In the case where builds are executed headlessly or on a different machine, this can allow faster navigation of test failures.
PDE has been updated to allow the root of an OSGi bundle to reside at any level of the filesystem hierarchy, rather than solely at the top level. This should allow easier interoperation with tools which put resources (such as META-INF/MANIFEST.MF) in other locations. In addition, the PDE builder (which uses information stored in build.properties) now has more in-sync checks with the corresponding .classpath of the project, which will hopefully lead to earlier and easier detection of errors between in-IDE projects and the exported builds.
The OSGi runtime underneath Eclipse, Equinox, has been extended to support both declarative and programmatic registration of ServletFilters. Combined with the upcoming release of the OSGi EEG, this should allow Eclipse to trivially host web-applications inside a running instance. Furthermore, the bytecode weaving (used by AspectJ) is now supported and distributed with Equinox. Lastly, it is now possible to startup multiple Equinox consoles rather than just relying on a single console as before.
The launching framework (used for starting external programs, ant builds, PDE launches etc.) has been decoupled from the UI, which makes it easier for headless tools to be able to reuse launches from headless tools.
OSGi users will also appreciate that the EventAdmin is now bundled as part of Eclipse RCP, rather than requiring a different download in order to make use of it. Furthermore, ECF now fully supports remote services and so this should be a bigger part of distributed Eclipse Equinox systems in future.
For more information about Event Admin and Remote Services, follow InfoQ’s Java Modularity series.
by Alex Blewitt
This a remarkable day in the history of UFaceKit because since today we can provide consumeable nightly builds to install or create a target platform.
A big thank you to Chris Aniszczyk and Pascal Rapicault who helped me in getting my build in shape – I hope to meet you at EclipseCon and pay you some beers.
Let’s take a look how one get his/her hands dirty on UFaceKit for SWT:
Now we are ready to create our first UFaceKit-Application:
The project is now configured appropriately. Now let’s create an HelloWorld-Application. Open the Application.java-File and make it look like this:
import org.eclipse.core.runtime.IStatus;
import org.eclipse.core.runtime.Status;
import org.eclipse.equinox.app.IApplication;
import org.eclipse.equinox.app.IApplicationContext;
import org.eclipse.ufacekit.core.util.DataRunnable;
import org.eclipse.ufacekit.ui.core.UIDesktop;
import org.eclipse.ufacekit.ui.core.UIRunnable;
import org.eclipse.ufacekit.ui.core.controls.UIApplicationWindow;
import org.eclipse.ufacekit.ui.core.controls.UIButton;
import org.eclipse.ufacekit.ui.core.controls.UIButton.ButtonUIInfo;
import org.eclipse.ufacekit.ui.core.controls.UIApplicationWindow.ApplicationWindowUIInfo;
import org.eclipse.ufacekit.ui.core.controls.util.Rectangle;
import org.eclipse.ufacekit.ui.core.layouts.UIFillLayout;
import org.eclipse.ufacekit.ui.jface.core.JFaceFactory;
public class Application implements IApplication {
public Object start(IApplicationContext context) throws Exception {
JFaceFactory f = new JFaceFactory();
final UIDesktop dk = factory.newDesktop();
UIFillLayout layout = f.newFillLayout();
ApplicationWindowUIInfo d = new ApplicationWindowUIInfo(layout);
final UIApplicationWindow window = f.newApplicationWindow(dk, d);
window.setText("UFaceKit - Hello World");
ButtonUIInfo d1 = new UIButton.ButtonUIInfo(null)
UIButton button = f.newButton(window, d1);
button.setText("Click me");
button.setActionRunnable(new UIRunnable<UIButton>() {
@Override
protected IStatus run(UIButton arg0) {
DataRunnable<Boolean> run = new DataRunnable<Boolean>() {
public void run(Boolean arg0) {
if( arg0 ) {
System.out.println("Good Boy/Girl");
} else {
System.out.println("Too bad.");
}
}
}
dk.showQuestionDialog(window, "Question", "Do you like UFaceKit?", run);
return Status.OK_STATUS;
}
});
window.open();
window.setBounds(new Rectangle(500, 400, 400, 100));
dk.run();
return IApplication.EXIT_OK;
}
public void stop() {
// nothing to do
}
}
I think the code is quite self-explanatory but there are some remarkable things you should have noticed:
I’m going to transfer this content over to UFaceKit-Wiki in the following days and write other tutorials on how to exploit other features of UFaceKit like:
One more note: The UFaceKit-SWT port is feature complete and stable since about 6 months and there hardly any todos before releasing 1.0.0 of the SWT-Port so it’s really useable and I hope that some people give it a try and report back problems so that I can release a very stable build.
The only real blocker for a 1.0.0 release is that the test suite is not completed yet and I won’t release before having a complete test suite which helps me to avoid regressions in future versions and ensure compability of future platform ports to the API contract defined.
Preamble: This is the first post of the new Eclipse category of BonitaSoft’s community blog. As soon as we find something interesting to talk about when developing Bonita Studio, we will try to share what we learnt with our communities: BonitaSoft and Eclipse. We are also pleased to see this category aggregated to Planet Eclipse knowledge feed. We hope you’ll enjoy reading these posts!
The Bonita Studio developers crew
I found some time recently to take a look at SWTBot to check whether we should use it while developing Bonita Studio (part of Bonita Open Solution, based on Eclipse Gelileo 3.5.1). After a few minutes of reading wiki pages and trying it, I was convinced that SWTBot (and its GEF extension, that also works for GMF) is a must-use project for anyone who has ever it found difficult and time-consuming to write plugin tests.
Only a few hours later our continuous integration build welcomed our first SWTBot based test!
Here is the step-by-step of this awesome encounter:
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
package org.bonitasoft.diagram.test;
import org.bonitasoft.studio.model.process.diagram.part.ProcessDiagramEditor; import org.eclipse.swtbot.eclipse.finder.widgets.SWTBotEditor; import org.eclipse.swtbot.eclipse.gef.finder.SWTBotGefTestCase; import org.eclipse.swtbot.swt.finder.junit.SWTBotJunit4ClassRunner; import org.eclipse.swtbot.swt.finder.widgets.SWTBotMenu; import org.eclipse.ui.IEditorPart; import org.junit.Assert; import org.junit.Test; import org.junit.runner.RunWith; /** @Test |
:
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
@RunWith(SWTBotJunit4ClassRunner.class)
public class DiagramTests extends SWTBotGefTestCase { @Test |
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
<echo>SWTBot test</echo>
<java dir=“${eclipse.test.home}” fork=“true” output=“${eclipse.test.home}/output.txt” logError=“true” classname=“org.eclipse.core.launcher.Main” failonerror=“false”> <classpath> <fileset dir=“${eclipse.test.home}/plugins”> <include name=“org.eclipse.equinox.launcher_*.jar”/> </fileset> </classpath> <arg line=“-application org.eclipse.swtbot.eclipse.junit4.headless.swtbottestapplication”/> <arg line=“-testPluginName org.bonitasoft.studio.diagram.test”/> <arg line=“-testApplication org.bonitasoft.studio.application.application”/> <arg line=“-className org.bonitasoft.studio.diagram.test.DiagramTests”/> <arg line=“formatter=org.apache.tools.ant.taskdefs.optional.junit.XMLJUnitResultFormatter,junit-results.xml”/> <arg line=“-nl fr”/> <arg line=“-consoleLog”/> <jvmarg line=“-Xms40m -Xmx348m -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError”/> </java> |
Congrats and thanks to SWTBot developers for making this possible! We love playing with it when developing Bonita Open Solution!
If someone has a better solution for this integration, please tell me!