Eclipse Platform on Ulitzer

When I first started asking Eclipse developers about provisioning and lockdown - do we need it, what did they think about it, etc. - several things became clear very quickly. First, there are two distinct camps - people who manage people using Eclipse and people who use Eclipse. The people who manage developers and projects using Eclipse expressed great interest in being able to manage the Eclipse tool stack running on the developers' desktops. On the other hand, the developers actually using Eclipse expressed not just a lack of interest, but an actual dislike and resentment for anyone having control or lockdown of their Eclipse configuration.

The second observation, which is really derived from the first, is that using the term "lockdown" when talking to developers about provisioning and managing an Eclipse tool stack is certain to alienate many developers. In fact, when asked what he thought about locking down his Eclipse environment, one developer responded, "That would really, really [make me angry]. I can't imagine anyone who uses Eclipse actually being happy about that."

Furthermore, most developers would quickly point out, almost as though issuing a challenge, it is nearly impossible to completely lockdown an installation and prevent a user from adding, removing or updating plug-ins from their Eclipse environment.

In the interest of getting you to read past the first few paragraphs of this article, let me be very clear, this article is not about Eclipse lockdown. I have no persuasive arguments, customer data, analyst research, or even anecdotal evidence that suggests anyone really, truly wants to create a tool stack based on Eclipse and then have it cast in stone never to change again. This article is, however, about provisioning, managing, and maintaining the integrity of an installed Eclipse-based development environment.

Coincidently, the same developer mentioned earlier went on to say this about lockdown, "I could see it being a useful capability to set a baseline within a company. Providing managed, certified builds and a central repository for them - cool idea... but really you can do the same thing from a Wiki". And that is really the point here. Even the act of posting information to a Wiki can be problematic. Why not take it a step further and just make it possible to capture and upload/download the profile directly from the development environment?

For our purposes, let's define the notion of a development environment to include:

• The Eclipse-based tool stack
  -The base IDE (Eclipse, JBuilder, MyEclipse, IBM RAD, etc.)
  -All additional Eclipse add-ons (Subversive, Mylyn, etc.)
  -All selected add-ons (commercial, open source, internal, third-party, etc.)
• Relevant projects in the workspace
• Including versions, branches and working sets
  -Workspace preferences
• Source code formatting and style preferences
  -Boilerplate copyright notice comments
  -Other company standards

One of the biggest challenges faced by many organizations that use an Eclipse-based tool stack as part of their software development process is how to deal with the growing number of variants of "the standard development environment" that show up within their development teams. One of the greatest strengths and benefits of Eclipse is that it gives developers the option and ability to create a development environment that is perfectly suited to their needs. If you are a team of one this rarely causes an issue, although there is still a case to be made for provisioning even for one person, but more on that later.

What happens when you are part of a team working on a project, and you update a plug-in because you found a newer version that fixes a bug, or you change a workspace property to point to a different JRE than everyone else is using? Yes, you could send out an email or post something on the project Wiki. More often then not once you have something working, which usually means you were distracted from your main development task to begin with, you just go back to what you were doing and ultimately forget to share this information or knowledge with your team members. Eventually, they'll stumble across the same issue with the plug-in you already dealt with, and have to repeat all the work you've already done to find the updated plug-in, install it, verify that it works in your environment, and then hopefully remember to tell the other developers so that this pattern isn't repeated across the team.

There's got to be a better way. What is really needed is a solution that provides centralized management of these configurations including creating, updating, validating, synchronizing and, most important, sharing of profiles. Think of it as a provisioning cloud - either public or private - for your Eclipse-based tools. Now, I'm sure many of you are thinking, "Doesn't Eclipse already provide provisioning with Equinox/p2 or even Buckminster?" and the short answer is "it depends on how you define provisioning." Some things to consider are how much of the stack and development environment can be provisioned by the system, what granularity does the provisioning system support, can you update or version provisioned profiles, does the provisioning system support incremental (e.g., deltas) updates or only complete reinstalls, can you create your own profiles or are you limited to a set of predefined profiles, and so on.

Some examples of open source and commercial provisioning solutions available today are Eclipse Equinox/p2, Eclipse Buckminster, Genuitec Pulse, EclipseSource Yoxos, and OpenLogic Exchange (OLEX). While each of these tools positions themselves as a way to provision Eclipse, it is clear that they all do something very different. Common differences include what is being provisioned, how it is provisioned, and the extent the user can update or manage provisioned profiles. For instance, Equinox/p2 is targeted at refreshing the client-side provisioning infrastructure in Eclipse and replaces the Update Manager as a mechanism for managing your Eclipse install, searching for updates, and installing new functionality. Buckminster on the other hand is a set of frameworks and tools for automating the build, assemble & deploy (BA&D) development processes in complex or distributed component-based development. Pulse, Yoxos, and OLEX offer verified or certified Eclipse plug-in bundles. In short, each system has its own bells and whistles.

I think it is worth mentioning that even with the improvements that have been made with p2, and there have been many, there are still some limitations. According to the Equinox p2 Getting Started Wiki page, if you manually remove a plug-in installed by p2, or attempt to replace it with a different version, p2 will not detect this and may end up broken. This issue is partially overcome with the new drop-ins folder that is more powerful and allows separation of content managed by p2 from content managed by other means. However, this just means there is another directory of content that has to be managed by someone, somewhere, somehow if that content is to be shared with the development team.

At this point you're probably asking yourself, so what does it take to make a good provisioning system? I think we can safely assume and agree that there are already solutions available that provide a way to create an initial tool stack comprised of certified, validated bundles. What we really want to focus on is how to create a snapshot of a defined development environment including both the complete tool stack and workspaces that can then be easily managed, maintained and shared with other members of the development team. Here are some key capabilities to look for when considering such a provisioning solution:

Quick and Easy Eclipse Installation
A designated person typically spends days downloading, installing, configuring, and testing different combinations/versions of the Eclipse IDE and additional plug-ins from multiple sources (open source, proprietary, internal). Once he or she gets all the ducks to line up, they produce a Wiki page documenting the procedure so that it can be replicated by the entire team.

Having a quick and easy way to capture the certified configuration and then make it available to others as a single pre-packaged install eliminates the redundancy of each person doing this work by hand and minimizes the chance for error.

Quick and Easy Workspace Provisioning
After you install your IDE, the next step is to set up your workspace. The workspace setup typically includes:

• Workspace preferences: CheckStyle, company copyrights, etc.
• Workspace content: The projects you need to check out from source control into the workspace, the versions and branches you need, etc.

When done manually, workspace setup is error-prone and time-consuming. The steps are posted in a document on the Wiki and every new developer is pointed to that document.

Even in the best-case scenario where the Wiki is actually kept up-to-date, the setup may take hours. If you misread or skip a step, then it takes much longer and you are very likely to go ask for help from a team mate resulting in more time lost.

Here again having a simple, automated way to capture the workspace settings and properties and then make it available from a central repository means reducing setup time and eliminating error-prone manual steps.

Automatically Detect Out-of-Date Workspace / Maintain Workspace Currency
As time goes on, the workspace content inevitably changes. Plug-ins, dependencies or preferences are added, removed or modified regularly. Even in the ideal world where the Wiki instructions are kept up-to-date and e-mail notifications are sent out regularly by the team, you can still easily fall behind by not keeping up with the latest changes. When you come back to work after a week of vacation, it is not uncommon to see that your workspace does not compile anymore. You try to get out of the broken state by doing incremental updates. Sometimes that works, other times it doesn't. You decide after a few hours of tinkering that starting over from scratch may be the only viable option left, so you spend half a day doing it.

If the development environment could detect or recognize when a workspace was out of date based on an established baseline, present the user with the differences and then allow him to easily reconcile those differences without having to manually compare plug-in by plug-in, workspace property by workspace property there would he a significant time savings.

Maintain the Integrity of the Tool Stack and Workspace
In an Eclipse-based product where all the plug-ins are integrated seamlessly, a single bad plug-in can destabilize the entire product by making it crash (e.g. memory hogs/system resources leakers) or become sluggish.

An unstable configuration therefore results in costly downtime.

Similarly, to ensure code consistency, companies typically have standard CheckStyle settings, company copyrights, compiler warning levels, JDK version, etc., that every developer must use. Deviations typically cause build breakage, resulting in more downtime.

Being able to maintain the integrity of the configuration and provide developers with a well-defined, well-tested configuration which can only be altered under certain circumstances could save companies and developers significant time, which in turn results in cost savings.

Extended Plug-in Configuration
Experimentation is good. If a developer independently searches for and finds a well-behaved plug-in that helps increase his productivity, he would want to share this plug-in with the rest of his team. But first, the plug-in should be evaluated by an administrator or someone overseeing the project before it gets added to a profile and deployed to the rest of the developers.

Having a mechanism in place for the developer to nominate a plug-in for inclusion and prompt the admin for evaluation would be extremely beneficial. Upon approval, the approved plug-in then gets deployed to the rest of the team.

Statistics and Reporting
Providing data on which profiles are being used and by how many users, what updates are made to each profile and how frequently, and other such statistics can he useful to managers and administrators.

Before concluding I wanted to come back to that "team of one" idea I mentioned earlier. I would submit that even as an individual developer you could realize substantial benefit from a provisioning solution to help manage and maintain either different tool stack configurations or different workspace configurations. Having the ability to install and test new plug-ins or new versions of plug-ins during development, or change workspace settings for testing purposes, and then quickly rollback to a baseline configuration can save hours of having to manually undo all the changes.

So where does this leave us? Certainly there is much more discussion that should and will take place around the concept of Eclipse provisioning. One of the biggest benefits of the Eclipse framework has led to one of biggest challenges, but also to some incredible opportunities. Software vendors such as Embarcadero Technologies and others are working on Eclipse provisioning solutions that will offer managers, administrators, development teams, or even individual developers the ability to centrally manage, validate, synchronize and share their tool stack and workspace profiles. By marrying together ideas and technologies from application provisioning, SaaS, and cloud computing there promises to be some exciting advancements in this area. Solutions that will help you create, maintain and share profiles of a known, trusted development environment without giving up the flexibility to modify and evolve the environment as necessary. It short - without locking it down.