by Erik C. Thauvin (erik@thauvin.net) at July 30, 2010 10:26 PM

Byron Nevins has posted a very nice blog on offline configuration for Glassfish v3.1 here.
The following blog will show how to deploy a webservices application to a Glassfish 3.1 cluster . You can do additional tasks using the Glassfish Administration Console.
For this blog I tried with the latest promoted b13 of Glassfish 3.1 available here.
Steps
1.Install Glassfish b13 on both machines (jwsdp and adc2180404)
2.DAS is on adc2180404 other instance is on jwsdp
3.asadmin start-domain
Waiting for the server to start .....
Successfully started the domain : domain1
domain location: /scratch/bhamehta/gf-install/glassfishv3/glassfish/domains/domain1
Log File: /scratch/bhamehta/gf-install/glassfishv3/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.
4.asadmin create-cluster mycluster
Command create-cluster executed successfully.
5. asadmin create-node-config --nodehost jwsdp jwsdpconf
Command create-node-config executed successfully.
6.asadmin create-instance --cluster mycluster --node jwsdpconf mycluster_i1
Successfully created instance mycluster_i1 in the DAS configuration, but failed to create the instance files. Please run:
asadmin --host adc2180404.us.oracle.com --port 4848 create-local-instance --node jwsdpconf mycluster_i1
on jwsdp to complete the transaction.
Command create-instance failed.
7(On jwsdp)asadmin --host adc2180404.us.oracle.com --port 4848 create-local-instance --node jwsdpconf mycluster_i1
Attempting to rendezvous with DAS on host adc2180404.us.oracle.com port 4848
Uptime: 1 minutes, 58 seconds
The instance has rendezvoused with the DAS and will be using host adc2180404.us.oracle.com port 4848 for future communication.
servers.server.mycluster_i1.config-ref=mycluster-config
servers.server.mycluster_i1.lb-weight=100
servers.server.mycluster_i1.name=mycluster_i1
servers.server.mycluster_i1.node=jwsdpconf
servers.server.mycluster_i1.property.rendezvousOccurred=true
Command create-local-instance executed successfully.
8(On jwsdp)./asadmin start-local-instance mycluster_i1
Waiting for the server to start ............
Successfully started the instance: mycluster_i1
instancelocation: /Users/bhakti/gf-install/glassfishv3/glassfish/nodeagents/jwsdpconf/mycluster_i1
Log File: /Users/bhakti/gf-install/glassfishv3/glassfish/nodeagents/jwsdpconf/mycluster_i1/logs/server.log
Admin Port: 24848
Command start-local-instance executed successfully.
Now deploy a webservice I tried deploying the war which we developed as part of this blog http://weblogs.java.net/blog/bhaktimehta/archive/2010/06/24/ejb-webservi... and could access the wsdl from the instance.
9.(on adc180404 DAS) asadmin deploy --target mycluster /scratch/bhamehta/ejbwsinwar.war
The application should be deployed on the instance. You can test it using the tester. In my case the machine on which the instance was running was jwsdp
I tried deploying the war which we developed as part of this blog http://weblogs.java.net/blog/bhaktimehta/archive/2010/06/24/ejb-webservi... and could access the wsdl from the instance.
http://jwsdp:28080/WeatherService/Weather?wsdl
To deploy on the das you will need to create an application ref like this
10./asadmin create-application-ref ejbwsinwar
Now you can access the wsdl on the DAS too http://localhost:8080/WeatherService/Weather?wsdl
You can also launch the Glassfish Admin Console on the DAS (Note admin console will not be available on the instances)
in my case we launch the Glassfish Administration console on this location http://adc2180404:4848/
The following image shows a snapshot of the Glassfish Administration Console
Under the applications tab you can see the ejbwsinwar .

You can also click on Common Tasks and List the deployed applications, deploy applications, manage the targets etc.
| Attachment | Size |
|---|---|
| adminconsole.png | 158.39 KB |
A new release of Saros has been released today. A lot of new stuff is packed into this one.
Firstly, Saros is now version control system (VCS) aware. You now have the choice of sharing a project by sending SVN repository information to your peers, so that they can interact directly with the repository. More functionality in this feature will follow in later releases!
We’ve also improved the chat view a little. The visual layout is nicer, it has a configurable beep for received messages, and one joins/leaves the chat session automatically.
In addition to that, there is a large batch of bugfixes and miscellaneous improvements. The Sourceforge site is here, or the Eclipse update site is here.

Many have downloaded, looked at, and have commented on the source code for the attachment viewer project but some may not be aware of a powerful function the SWT Browser brings to the table. As described in a past post about the architecture, the line where the browser is connected with the embedded browser process (its actually a dotted line) is where this call happens. The function, or method, is the execute method on the SWT browser. This allows you to run essentially any JavaScript on a given web page or DOM. The attachment viewer uses this method to call a JavaScript function named “showAttachments()”. The Eclipse Java code takes the current selection – which in this case it looks for IAttachment – and then passes a set of URL’s and JSON to that JavaScript function. This is how easy it is to “connect” the web world with the Eclipse world.
String cmd = "showAttachments(" + jObj.toString() + ");";
if (browser.execute(cmd) == false){
The kind fellows at the Planet Eclipse community have consented to aggregate this blog as a resource for the dissemination of information on Saros. They have recommended that I author a post to serve as a beginner’s guide.
To that end, I’ve put together a new static page about Saros. Enjoy.

by Erik C. Thauvin (erik@thauvin.net) at July 30, 2010 07:00 AM
About 48 hours ago I was describing my first small step to get ChangeSet implemented. Two days is a lots of time, and current status of this feature can be described by this screen shot:
As you can see, the „Git Change Set” appears next to the standard change set representation, this can be changed using third tool bar button (from left hand side).
Currently list of commits contains only commits between base and destination rev, the common ancestor isn’t included or even dispatched by the change set implementation (this can, or even should, be changed). Also there should be included proper graphical representations for commits, folders and files; additionally compare view should be launched when we double click on file. That things should be improved/fixed before I’ll publish code.
Beside that small issues I think that right now it is the best time to start discussion how we (yes, me and you!) would like to use this feature and have it should behave and and look. What you can see in above screen shot is only my proposition and (as always) I’m open for any suggestions and ideas. The best place for this discussion is Eclispe’s Bugzilla and bug 318473, and I encourage you to share yours opinion with us!
I’m looking forward for any feedback about this feature
BTW. One of thins that I’m proud of, in current implementation, is that I haven’t use any kind of internal API of Team Framework ;>
![]() |
SunSolve was, and still is, Sun's way of distributing patches; the equivalent mechanism at Oracle is My Oracle Support (MOS), and Gerry just announced thatSun patches now available there. This includes the GlassFish commercial patches like 128640-20, which is one of the patches in GlassFish 2.1.1 patch 6. I just looked directly for the patch ID (using Sun's patch number), I'll try to dig more info on how to use MOS and will post it later on. |

The JVM Summit'10 is finished !
As last year and the year before it was fun, amazing and mind blowing to discuss and share ideas with brilliant people of the Java & JVM community.
If you want a fast forward glimpse of the state of the JVM languages future presentations are available on the wiki:
http://wiki.jvmlangsummit.com/Main_Page
cheers,
Rémi
| Attachment | Size |
|---|---|
| 800px-Rose-iphone-IMG_0023.jpg | 46.11 KB |
Page 348 — The steps in section 20.3.1 suggest that you should use the Target Platform Export wizard to get the base set of bundles against which you can build your system. It turns out that that wizard is only available in Eclipse 3.6 (Helios) and later. To date we have been unable to back port that function to Eclipse 3.5.2 (Galileo). To work around this, you can either
Note that if you choose the latter approach there may be some minor issues as the book samples and workflows have been tested most rigorously with Eclipse 3.5.2.
To gauge the quality of code, we’ve all seen the metric called WTF/minute.

I’m inventing a new metric, called the WTF/loc, based on this very short snippet of code.
#!/usr/bin/perl
use strict;
my $cmd = "perl " . shift;
my $h = <STDIN>;
while ($_ = <STDIN>) {
open (S, "| $cmd");
print S $h;
print S;
for (2..1000) {
last unless $_ = <>;
print S;
}
}
A few comments to explain what’s going on would have made this snippet of code much more maintainable.
REST Web Services can be particularly difficult to test, with the need for networking, a web container, multiple threads and transaction management creating extra complexity beyond your standard unit test. In this article I demonstrate patterns designed to address this complexity while enabling complete testing of your REST web service stack.
The ideal web service unit test will use the same principles discussed in my previous article:
In addition, we’ll need to run a web container for our unit test. To maintain a zero-setup test environment, we’ll have our unit test start a web container for the purpose of running our web service. By having each test start and stop the web container, tests become very simple to run and we’re guaranteed that our tests will have a clean environment with no external dependencies.
Normally starting a web container is difficult to do in a unit test, and container startup time can be a problem — however with the right choice of web container we can overcome these problems. Winstone is a small, fast web container that is designed to be embedded in Java programs. By using Winstone, we’ll be able to start and stop the web container as part of our unit test setup and tear-down with relative ease.
Starting Winstone is as simple as this:
Map args = new HashMap();
args.put("webroot", pathToWebRoot);
args.put("httpPort", String.valueOf(port));
Launcher.initLogger(args);
// start winstone
winstoneLauncher = new Launcher(args);
Winstone only takes a couple of seconds to start up. Shutting it down is as simple as this:
if (winstoneLauncher.isRunning()) {
winstoneLauncher.shutdown();
}
To hide the details of winstone from our unit tests, we can create a class WebApplicationContainer, which is responsible for starting choosing a port, starting/stopping Winstone, and providing a base URL for our tests:
public class WebApplicationContainer {
private static final Random random = new Random(System.currentTimeMillis());
private Launcher winstoneLauncher;
private File webRoot;
private int port;
/**
* start the webserver, guarantees that the webserver is started upon return.
* @see #stop()
*/
@SuppressWarnings({ "unchecked", "rawtypes" })
public void start() {
if (winstoneLauncher != null) {
throw new IllegalStateException("already started");
}
port = findAvailablePort();
Logger log = Logger.getLogger(WebApplicationContainer.class.getName());
log.fine("Starting web container on "+getBaseUrl());
Map args = new HashMap();
try {
args.put("ajp13Port", "-1");
args.put("useJasper", "false");
args.put("webroot", webRoot.getAbsolutePath());
args.put("httpPort", String.valueOf(port));
Launcher.initLogger(args);
// start winstone
winstoneLauncher = new Launcher(args);
// wait for Winstone to finish starting up
// we do that by attempting to connect via socket
final int maxRetries = 150;
for (int x = 0; x < maxRetries; ++x) {
if (testForSuccessfulStartup()) {
break;
}
if (x == maxRetries - 1) {
throw new IllegalStateException(
String.format("Connection to localhost:%s failed."+
" Did the web container start up successfully?"));
}
// wait and then try again
Thread.sleep(100L);
}
Logger.getLogger(WebApplicationContainer.class.getName()).
info("Started web container at "+getBaseUrl());
} catch (Exception e) {
throw new IllegalStateException(e);
}
}
private int findAvailablePort() {
...
}
private boolean testForSuccessfulStartup() {
// test to see if the web container is listening on the address/port combo
try {
Socket socket = SocketFactory.getDefault().createSocket("localhost", port);
socket.close();
return true;
} catch (UnknownHostException e) {
throw new IllegalStateException(e);
} catch (IOException e) {
return false;
}
}
/**
* stop the web container
* @see #start()
*/
public void stop() {
if (winstoneLauncher == null) {
throw new IllegalStateException();
}
winstoneLauncher.shutdown();
winstoneLauncher = null;
}
public String getBaseUrl() {
return String.format("http://localhost:%s/", port);
}
...
}
A complete test for our web service ends up looking like this:
@RunWith(SpringJUnit4ClassRunner.class)
@Transactional
public class BlogServiceClientTest extends BlogServiceTest {
@Autowired
private BlogServiceClient blogServiceClient;
@Autowired
private WebApplicationContainer webContainer;
@Before
public void before() {
webContainer.setWebRoot(computeWebRoot());
webContainer.start();
blogServiceClient.setBaseUrl(webContainer.getBaseUrl()+"api");
// use the client instead of the service directly
service = blogServiceClient;
}
@After
public void after() {
if (webContainer.isStarted()) {
webContainer.stop();
}
}
}
You might be thinking "where are the @Test methods?". The beauty of our web service test is that it extends our service test: all of the test methods we were running before using direct method calls are now also run over our web service protocol. By using inheritance, other than setup of our web service there’s nothing else to do. In other words, our service tests are run twice: once using Java method calls, and again over-the-wire using our web service. This ensures that we see consistent behaviour in both modes of execution.
BlogServiceClient is an implementation of BlogService (our service interface under test) based on Spring’s RestTemplate. It’s a REST client for our service, implementing the same Java interface as our server-side service. This enables us to substitute the REST client service implementation in our test.
Now that we’re able to start our web service and run tests we’re done, right? Not quite: we still need to manage transactions and our test data. This is somewhat more complicated with our web service: recall that we want our unit test to have the following qualities:
Employing the techniques we’ve already established in Patterns for Better Unit Testing with JPA helps, but is not quite enough.
Our service implementation is running in a web container. The web container services incoming HTTP requests with threads in a thread pool. Our service is pretty much guaranteed to be running on a distinct thread, not the same thread as that running our unit test method. As a result our service bean will be running in it’s own transaction context. There are two problems that arise from this:
Both of these things are undesirable. To overcome this problem we’ll apply a little trickery: we’ll provide an entity manager that is shared by both the test thread and the web container thread servicing our HTTP requests, and we’ll prevent any commit or rollback from occurring on that entity manager while it’s in use in a unit test. We do this by wrapping the entity manager factory in our test environment:
<bean class="greensopinion.restexample.test.jpa.TestEntityManagerFactory"
id="blogDomain">
<property name="delegate">
<bean
class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="persistenceXmlLocation"
value="classpath*:/persistence-test.xml"/>
</bean>
</property>
</bean>
Our TestEntityManagerFactory employs the standard delegate pattern, with the exception that it changes the default behaviour of createEntityManager():
public EntityManager createEntityManager() {
if (theEntityManager == null) {
theEntityManager = delegate.createEntityManager();
}
return new TestEntityManager(theEntityManager);
}
It creates and returns a singleton entity manager instance. This allows us to share a single entity manager between our unit test and the web container. We also wrap the entity manager so that we can control it’s lifecycle (we prevent close()) and that of it’s transaction (we prevent commit() and rollback()).
While we know that the EntityManager is not thread safe, it’s okay to share it between threads providing that no two threads access it at the same time. Since our REST client will block on any calls to the server, we’re not at risk of concurrent access.
Complete, working source code demonstrating these patterns and others is available on GitHub:
http://github.com/dgreen99/greensopinion.restexample
The source contains two Eclipse projects: one for the web application, and one for unit tests. The unit tests all run and pass, and the web application can be started and deployed with a MySQL database.
The service is split into the following:
This gives us a good separation of concerns, and client code need not always know if it’s calling an in-process or out-of-process service.
JPA domain objects are exposed by the service interface. This helps in a few ways:
However it has drawbacks:
This approach may be feasible for some projects. It’s common to see transfer objects as well, which allows a service to be explicit about it’s data model without exposing the domain implementation details.
Notably this sample code is missing two crucial aspects of a normal web application:
These aspects of the sample application are left unimplemented.
Testing REST web services can be easy by following the following patterns:
By applying these straight-forward techniques it’s possible to overcome the complexity inherent in testing a web service, enabling better coverage and higher quality applications.
Technologies used in this project:
by David Green (noreply@blogger.com) at July 29, 2010 01:16 PM
Every once in a while I am reminded of the lunacy of the Internet, especially headline writers. On Monday of this week, Oracle released an update to the Java 1.6 update 21 that fixes a problem in a previous version that broke Eclipse. All the details can be found in the bug or Neil’s good summary. The good news is that Eclipse is no longer broken!!
The irony however is that the issue just yesterday shows up on Ed Burnette’s ZDNet blog ‘Oracle Rebrands Java, breaks Eclipse‘ and the pillar of all Internet lunacy, slashdot Oracle Java Company Change Beaks Eclipse . Credit to Ed for actually reporting and testing the fix. However, the slashdot posting is the following:
crabel writes “In Java 1.6.0_21, the company field was changed from ‘Sun Microsystems, Inc’ to ‘Oracle.’ Apparently not the best idea, because some applications depend on that field to identify the virtual machine. All Eclipse versions since 3.3 (released 2007) until and including the recent Helios release (2010) have been reported to crash with an OutOfMemoryError due to this change. This is particularly funny since the update is deployed through automatic update and suddenly applications cease to work.
No mention the problem has been fixed and wrong on the fact the update was deployed through automatic update; update 21 hadn’t been pushed out yet via automatic update. Of course the typical slashdot comment ensued, granted some of the comments do point out the reality. However, as with anything on slashdot, people repeat the headline “Oracle’s Java Company Change Breaks Eclipse” on things like twitter, so the meme continues. Let me be clear, the problem is fixed: Oracle Demonstrates Great Community Support and Fixes Eclipse
Eric has already praised Oracle’s response to the situation. I would like to add my thanks to Oracle for quickly resolving the issue. I spoke to Oracle about the issue and I can tell you they had already decided to fix it before I spoke with them. Oracle should be applauded for their response to the bug. This type of bug could have easily lead to lots of finger pointing but Oracle just did the right thing for the community. THANK YOU

I tend to use IStatus whenever I can to indicate the status of some object. This have two severity states which are worth extra attention; ERROR and WARNING. Usually this object also have a graphical presentation, an icon. So would it not be nice to decorate this icon with an overlay image representing the severity of the status?

JFace's DecorationOverlayIcon comes to help. I usually use it like this:
private static final Point size = new Point(16, 16);
private Image getDecoratedImage(ImageRegistry registry, String baseImageId,
IStatus status){
ImageDescriptor overlay = null;
Image baseImage = registry.get(baseImageId);
switch (status.getSeverity()) {
case IStatus.ERROR:
overlay = PlatformUI.getWorkbench().getSharedImages()
.getImageDescriptor(ISharedImages.IMG_DEC_FIELD_ERROR);
break;
case IStatus.WARNING:
overlay = PlatformUI.getWorkbench().getSharedImages()
.getImageDescriptor(ISharedImages.IMG_DEC_FIELD_WARNING);
break;
default:
return baseImage;
}
// Construct a new image identifier
String decoratedImageId = baseImageId.concat(String.valueOf(status
.getSeverity()));
// Return the stored image if we have one
if (registry.get(decoratedImageId) == null) {
// Otherwise create a new image and store it
DecorationOverlayIcon decoratedImage = new DecorationOverlayIcon(
baseImage, new ImageDescriptor[] { null, null, null,
overlay, null }, size) {
};
registry.put(decoratedImageId, decoratedImage);
}
return registry.get(decoratedImageId);
}
Since images are system resources we must take care to release these when we no longer need them. So I'm using the image registry of the base image to store the decorated image. This will make the process a little bit faster when the same decorated image is needed again and it will also make sure that the resources are released when then system shuts down.
by Torkild U. Resheim (noreply@blogger.com) at July 29, 2010 09:25 AM
We are proud to make the first development version of the SWT/Qt platform available.
If you want to follow the progress of the code donation to the Eclipse Foundation you can track these bugs, CQ (link) and dicussion (link).
Please keep in mind this is a development version. All the core and custom widgets should work. However, it is not feature complete and it may be slow. Some things that are missing or incomplete are: StyledText, drag and drop, browser support, program start (launch external programs).
We provide binary bundles for the following OS:
We tested it with the following eclipse packages (Galileo SR2):
You need the SWT bundle (download) and one of the platform specific bundles (includes Qt):
For installation, simply replace the SWT bundles in your “eclipse/plugin/” folder with the ones you downloaded from us.
Due to a bug you have to start eclipse with the “-noSplash” parameter:
% eclipse -noSplash
To test the styling capabilities, and we are sure you want to, download the AdvancedStyler plugin (download) and place it in your “eclipse/dropins/” folder (restart required). It will help you playing with the amazing Qt styling. We included some examples for an easy start.
For more information look at the Qt Style Sheet documentation found here.
To launch the AdvanedStyler hit the little paint icon in the toolbar and a dialog will pop up where you can change the styling on the fly.
The AdvancedStyler dialog looks like this
Hitting “Reset” brings you back the default style. “Update” applies the current style to your SWT application.
We would like to know what you are thinking, so please leave a comment. We are also very interessted in how you would use the new possibilities to style an application. So please feel free to post or send us screenshots.
Happy styling …
UPDATE:
Updated the “Advanced Style” plugin. Now with menu item under “Edit”. (download v0.2.1)
Ed Burnette published an informative article on ZDNet about the recent incompatibility problem with Eclipse and Java 6 update 21. Unfortunately the comments contain a lot of nasty accusations and finger-pointing, with people variously blaming Oracle or Eclipse or both for the mess… and even Ed’s article title seems a trifle unfair on Oracle.
To address those who accuse Eclipse of inappropriately using an internal variable, consider for a moment why this was done. Here are the facts:
-XX:MaxPermSize but the “XX” part indicates this option is specific only to the Sun JVM and is not available on other JVMs such as JRockit, IBM J9 etc. In fact using it with those JVMs can cause them to simply emit an error and exit.-XX:MaxPermSize option. This cannot be done in Java because by the time the JVM has started it is too late, so it has to be done in the native launcher executable, i.e. eclipse.exe, which is coded in C. At this point the Java system properties are not yet available, but the properties in the exe/dll file are visible.So I don’t think Eclipse has done anything particularly wrong here. Neither has Oracle, there was no reasonable way for them to know that a simple rebranding would cause such a problem, and they responded very quickly to fix it.
Of course the fix is only a temporary one, as Oracle are going to want to change that variable eventually. So rather than pointing fingers, perhaps the Java community could try to come up with a real long-term solution. Such as a way to manage the JVM’s memory from within the JVM… or getting rid of the cursed PermGen altogether?
|
Alexis and Arun went to FISL11 at Porto Alegre (Wikipedia, GeoMap) and have provided reports including photos; see Alexis' Back from FISL, and Arun's AFISL 2010 Trip Report. Alexis's slides are available via SlideShare: GlassFish OSGi - from modular runtime to hybrid applications and The future of the GlassFish community. Arun's presentation was all demos, which he has also made available as a YouTube playlist. |
Open Source is very strong in Brazil (see for example this post). As you can see from our GeoMap, GlassFish has a fair amount of adoption, but we need to improve our outreach. If you have suggestions or want to contribute, post them as comments on this entry, or contact us at theaquarium at sun dot com.
As you know the Eclipse 4.0 SDK is out.
It also appears in discussions that some people don’t think Eclipse e4 is a good idea.
Other people seem to like it.
To help you to decide yourself I updated my Eclipse e4 Tutorial to Eclipse 4.0 Application Platform – Tutorial.
Together with Tom Schindls Tutorial you should be able to have a good start with Eclipse 4.0 SDK.
Please remember that the target of the core e4 Project is to improve the programming model of Eclipse and to provide an improved way of influencing the UI. The standard plugins are still the same and behave the same way.
My Tutorial also needs improvements, unfortunately it is not as far and deep as I like, but I hope that is will give you a good start. If you find issues, problems with my tutorial please let me know. The “more to come” section of my tutorial lists my future plans.
Summer madness has force me to leave a gap in the delivery of my award-winning “Eclipse is…” blog series. But I’m back now. In this series, I walk through the many different aspects of Eclipse, starting with the definition that most people are comfortable with: Eclipse is a Java IDE. But, as the series discusses, Eclipse is more than that. Technology-wise, Eclipse is a platform for building IDEs, tools, applications, runtimes, and more. Eclipse is open source projects. Lots and lots of open source projects covering a vast array of topics from modeling to identity management and object-relational persistence.
It’s certainly true that great technology is an important part of what makes Eclipse what it is. However, technology alone isn’t enough. Technology needs to have a community. And at Eclipse, we’ve got community. At Eclipse, we bring the community together to do great things.
Community is about coming together to do things as a group that no single person can do by themselves. Whether it be chasing snakes from a local watering hole, or building great technology and support.
Eclipse is actually a collection of communities that intersect. The Eclipse Development Process defines three different communities: users, adopters, and contributors/committers. Each of these communities has different requirements and expectations from Eclipse.
The first community, users, tends to regard of Eclipse primarily as a consumable product. They are primarily concerned with using an Eclipse-based IDE to build solutions. We estimate the size of this community to be between four and six million in size; though the fact that more than a million downloads of the new Helios packages occurred in the first month of availability leads me to believe that the community is even larger than our estimate.
The adopter community contains individuals and organizations that build solutions based on Eclipse technology. This can be as simple as providing a plug-in that runs in an Eclipse IDE, or as involved as basing an entire product on the Eclipse Rich Client Platform (RCP) or Rich Ajax Platform (RAP). It also includes those individuals and organizations who base a business on providing development assistance and support for Eclipse technology. One way or another, adopters tend to be building Eclipse plug-ins to provide solutions that directly or indirectly leverage Eclipse technology (though this is not necessarily the case as some Eclipse technology–like EclipseLink, and EMF–can be leveraged in plain-old-Java application). We don’t even try to estimate the size of the adopter community; it’s just too hard to do. There are more than a thousand “solutions” in the Eclipse Marketplace. This is really just the tip of the iceberg; it doesn’t include, for example, the bajillions of in-house applications (some of these are captured in case studies) that leverage Eclipse technology.
The contributor/committer community contains that group of individuals and organizations who contribute directly to Eclipse projects. These are the individuals who provide patches and/or contribute new functionality to the various Eclipse projects. Contributors tend to participate directly in an Eclipse project by providing code, ideas, answers to questions in the forums, and more. Committers are a subset of the contributors with write access to the resources maintained by a project (committer access is provided on a project-by-project basis). The idea is that over time, a contributor is invited to become a committer and elected into that position based on credibility established over a period of time. At last count we had almost a thousand committers and thousands of contributors (more than 11,000 individuals have contributed at least one patch to an Eclipse project).
Developing a community is an important part of being an Eclipse project. In fact, an integral part of the Eclipse Development Process. As part of a review process, a project is required to demonstrate their community-building activities, like blogging, speaking opportunities and more.
The graphic on this slide attempts to show that the various communities interact with each other. Users consume the software produced by the contributors/committers and the adopters, and provide feedback. Some subset of those users will provide feedback and other input into the project. Adopters also provide feedback and input. Some number of adopters may become contributors and ultimately committers. Projects with large communities have greater potential to have very diverse committer communities and broad consumption by adopters. There’s really more to it, but I’ll leave this discussion for a later post.
At this point in my presentation, I usually stop and ask the audience how many of them already have Eclipse Bugzilla accounts. Then, noticing that a large number of people haven’t put up their hands, I facetiously marvel that so many people have managed to use Eclipse for so long without ever having encountered any sort of problem. I use this opportunity to tell people that it’s okay to open bug reports (I once tried to use Erich Gamma’s bug-reports-are-like-love-letters analogy but decided that that wasn’t my style).
So, Eclipse is a community. A big community. A growing community. A diverse community. More than a community, though, Eclipse is… an Eco-System.
On a side note… committers: get your talk proposals for Eclipse Summit Europe in today!