The Eclipse Packaging Project defines pre-configured Eclipse distributions.  If you are develop in C/C++ there’s a package for that. If you need to create RCP applications there’s a package for that. Using p2 or the Eclipse Market Place you can customize your install until your heart’s content.

However, each time you download a new package, you’re most likely downloading the same 80-90M.  You are downloading SWT, JFace and maybe even the JDT over, and over and over again.  These Eclipse installs begin to clutter your machine and remembering which install contains which plug-in becomes practically impossible.  I currently have 17 different Eclipse installs on my machine:

Over the past few months I’ve been working on a solution to this problem, and now you can provision your own tool chain, the way YOU want it, from the cloud — and share all your plug-ins.  All you need to do is download and install the Yoxos Launcher.  When you start Yoxos, you will be prompted to select a pre-configured EPP Package (or you can also select “advanced mode” and create your own package).   You can even share the configurations between team members to help you get up and running faster.

All the artifacts are hosted on Amazon CloudFront, so the download should be pretty quick (I provisioned an entire ‘Eclipse Classic’ in under 5 minutes).  And all your plug-ins are shared between installs, so if you install a second package, Yoxos only downloads the new stuff it needs.

Using the Yoxos Customizer Perspective, you can add new components and craft your own customized Integrated Development Environment. The Yoxos repository holds almost 2,000 components including everything from Indigo.

Finally, you can set your upgrade strategy. That is, you can tell Yoxos that you want to receive all updates as they happen, or you would rather stick to an exact Eclipse version.

So to recap:

• Almost 2,000 components are available
• All the components have been tested to ensure that all required dependencies are available
• All the artifacts are hosted on the Cloud (AWS CloudFront)
• All your plug-ins are bundle-pooled and shared between installs
• You can configure your upgrade strategy
• The service is free, go ahead and try it.

Tags: indigo

What’s the latest version of Eclipse? Which version of Mylyn works well with Eclipse 3.6.2? How do you configure a toolchain for a project that was developed with Eclipse 3.5?

As an Eclipse committer I sometimes like to think the answer is simple: Use the latest milestone builds and the add-ons from the Indigo site. If that’s too bleeding edge then use Helios. While this simplistic advice is easy to follow, in many cases it’s not practical.  Many organizations have much stricter rules:

Development environments must be ‘reproducible’.  This is not as simple as each developer should use the same setup. This goes as far as to say, when working on legacy software, developers must use the exact same setup they did when the code was first written (say 5  years ago).

To achieve this, many organizations create VMWare images of their development environments and then share those among team members.  Workspaces settings are then managed by Zipping-up and Sharing the workspace directory.  While this chicken-wire and duct tape solution may work, it’s very difficult to propagate changes to your team.

This is the problem that Yoxos addresses and today I pushed the latest Eclipse release (3.6.2) to our Yoxos servers. With the latest version of the Yoxos Launcher you can now choose your upgrade path.  If you are happy with (or require Eclipse 3.6.1) you can now stick to that release.

On the other hand, you can stick to Eclipse 3.6.x, upgrading to new service releases as they become available.

Setting the appropriate upgrade path on your Yoxos profile will ensure that all your team members are using identical development environments and your current configuration will remain reproducible.  Team members simply need to install the Yoxos launcher and double click the profile.  This will get you up and running faster with Eclipse.

Yoxos supports 5 Different upgrade paths:

1. Sticky: Sticky means that you will never upgrade, and you will work with this toolchain forever.  This is important for enterprise customers if they have to re-create the exact toolchain (bugs and all) that was used in the past.
2. Critical: Critical means that nothing is removed, and only critical fixes are applied.  An example of this would be the upgrade from 3.6.1 to 3.6.1a (if a re-spin was needed for example).  If you set this, you will not get 3.6.2.
3. Service: Service will take any critical updates as well as automatically moving you to the next service release. For example, from 3.6.1 to 3.6.2. However, you will not get 3.7. Service updates may (highly unlikely) remove functionality. For example, if a plug-in specifies an exact dependency on 3.6.1, then this plugin will be removed in 3.6.2.
4. Minor: Minor updates will include all critical and service updates, as well as moving you to the next Minor release. For example, you will move from 3.6.1 to 3.6.2 to 3.7.0 (when 3.7 is released).
5. Major: Major updates will always keep you on the latest Yoxos slice. You will move from 3.6.1 to 3.6.2 to 3.7.. however, if there is a 4.0 slice, you will be moved here instead.  This is for those people who always want the latest!

With the latest Yoxos repository, we now have 1,677 Components (features) and over 10,000 Eclipse plug-ins.

I have tons of Eclipse workspaces. The last time I counted it was around 24, but it actually changes on a daily basis.

With some of my workspaces I want to have a similar IDE as with others, but some IDEs require special plug-ins. A while ago, as I still unzipped Eclipse-downloads, this was a huge pain. Every time I wanted to work in a specific workspace I had to remember which IDE I used for what, then find the workspace location on the disk, before I could do anything.

Permanent workspaces

Now I double-click a .yoxos file on my Desktop, then start working. Related .yoxos files hang out together on different areas on my desktop. This is possible with the Yoxos 5 Launcher which I explained in my last blog post.

I associate the workspace I want to start in terms of “upper right” or “vaguely in the middle, left” on the screen. No need to remember long directory names.
Remember, a .yoxos file is a definition of both the workspace and the IDE that works on the workspace. The actual workspace is somewhere in my home directory. Since every .yoxos file defines a separate IDE, I always click “Use this as default” after defining the first time where the workspace is located.

Temporary workspaces

Throwaway workspaces go to /tmp. Along with everything else in /tmp, they will be deleted the next time I reboot. The .yoxos file that defines a throwaway workspace should be deleted with it, so this belongs to /tmp as well. The IDE definition works this way:

• Start the Yoxos Launcher
• Add “Project SDK” and all the other desired plug-ins
• Save the .yoxos file to “/tmp/throwaway-workspace” (a new empty directory)
• Hit “Launch”

With the bundle pool I don’t worry about the plug-ins that compose the throwaway IDE. Only rarely something new gets downloaded anyway.

.yoxos files and workspaces

A special handling of .yoxos files in otherwise empty directories supports this workflow. If a .yoxos file is is started while residing in an empty directory, the IDE uses this directory as workspace. This provides an easy answer to the question about the “where”, and I use this feature at a regular basis.

On Mac OS X, I can append the extension “.yoxosws” to a directory that contains a .yoxos file. This defines a workspace that I can start directly with a double-click, without bothering about opening a folder to access the .yoxos file.

Conclusion

The Yoxos 5 Launcher makes it simple to handle a multitude of workspaces. The best thing is that you can stop wondering about the IDE contents and start thinking about workspaces. The Launcher provides a consistent UI to define new IDEs, including a huge number of 3rd-party plug-ins that are not shipped with the default Eclipse downloads.

Tags: yoxos

Back in the old days, maintaining an Eclipse installation was easy. You just downloaded the Eclipse; it included the JDK and you used this Eclipse on all your workspaces.

But the number of useful plug-ins increased, and many are not included in the downloads from eclipse.org. Developers use different plug-ins in different workspace. For some developers, this leads to as many Eclipse installations as workspaces. Others capitulated and just don’t use many plug-ins even though they see their value; but managing the installations is just too hard. Others again have one huge installation that includes about everything for all the workspaces, and they too have pain with plug-in dependencies. They all suffer from plug-in dependencies.

Imagine you had a system where each plug-in you use is downloaded just once and reused whenever you need it for a new Eclipse IDE.

Yoxos 5 provides that.

Imagine you could just start your workspace and your IDE starts up including all plug-ins you want to work with in that workspace. If it is a new workspace you’d have automatically adjusted predefined settings, import projects etc.

Yoxos 5 excels at that.

Yoxos 5 unifies the workspace settings and its IDE description in a Yoxos Profile. A Yoxos Profile can be defined in a .yoxos file. The Yoxos Launcher creates Yoxos Profiles and starts them, for example when double-clicking the .yoxos file. Plug-ins are downloaded to the bundle pool and started only if the profile includes them.

Yoxos 5 is now in beta phase. You can try it out now:

• Download and install the Yoxos Launcher
• Download and start one of the sample profiles (further down at the download page)

Get more information at http://eclipsesource.com/yoxos5

Tags: eclipse, yoxos