Content assist in in package-info files

and enhanced static analysis of case statements:

Checkout the entire new and noteworthy or download the milestone and try it out:

http://download.eclipse.org/eclipse/downloads/drops4/S-4.2M7-201205031800/

]]> http://eclipsesource.com/blogs/2012/05/05/eclipse-juno-milestone-7-available-for-download/feed/ 3 http://eclipsesource.com/blogs/2012/04/05/yoxos-configuring-your-bundle-pool/ http://eclipsesource.com/blogs/2012/04/05/yoxos-configuring-your-bundle-pool/#comments Wed, 04 Apr 2012 22:43:43 +0000 Ian Bull http://eclipsesource.com/blogs/?p=7430 Yoxos not only provides you with a way to pool all your plugins in a single directory, but you can also configure that location.  Eclipse/p2 bundle pooling means that different applications (different Eclipse configurations for example) can share the same set of bundles. This saves both time and disk-space as you don’t need to download the same bundle more than once.

Configuring this location is easy. In your Yoxos launcher directory, location the yoxos.ini file and adjust the following three settings:

-Dosgi.instance.area=@user.home/.yoxoslauncher/workspace
-Dyoxos.pool.p2.data.area=@user.home/.yoxoslauncher/p2
-Dyoxos.bundle.pool.data.area=@user.home/.yoxoslauncher

You can use path variables (such as @user.home) or absolute paths pointing to an external HD for example.

Make sure you download the latest Yoxos launcher from our downloads page.

I’ll be giving two presentations on p2 (and likely spending lots of time in the bar talking about p2).  The first presentation is a very gentle introduction to p2.  In this talk we will introduce p2 more pragmatically, presenting the relevant files (profile, content.xml, …), tools (director, mirror, …) and concepts.

In the second talk, It’s Raining Bytes, we’ll discuss how we scale p2 using a variety of cloud technologies.  In particular, we’ll discuss how we deploy over 64,000 plugins (and over store over 500,000 IUs) using different AWS services.

If you’re interested in p2, Yoxos, Eclipse releng, modeling or anything Eclipse related, look for me in the bar or stop by one of my talks.

I look forward to seeing everyone next week!

While many people are busy getting their talks finalized, suitcases packed, and studying their maps of Washington DC, the Eclipse and Equinox teams have been busy pushing towards another milestone for the Eclipse Juno Release.  Eclipse Juno (4.2) Milestone 6 is now available for download.

There are a number of new features, including:

Enhancements to the extension point editor:

Improvements to the editors bracket matching:

SWT Improvements (such as the ability to set custom colors in Color Chooser Dialog):

And a number of tweaks to the Java Development Tools such as selectively ignoring warnings on certain folders and CamelCase support in the quick outline view:

Checkout the entire New and Noteworthy, or download the milestone and give it a try:

http://download.eclipse.org/eclipse/downloads/drops4/S-4.2M6-201203151300/index.php

When most people think about dependency resolution they think about the requirements that must be present for an install to succeed.  However, that’s not the only type of requirement that exists.  Another requirement is a negation requirement. That is, something that must not exist for the installation to succeed.

A useful example of a negation requirement comes to mind when you think of  RAP (the Rich Ajax Platform). RAP is not intended to be installed into your IDE, but rather it’s meant to be installed in your target platform and deployed into a run-time environment.  If you do install RAP into your IDE then you’re asking for trouble (since RAP is an alternate replacement for SWT, your widget library).  RAP has traditionally used some pretty hacky work-arounds to ensure that it won’t be installed in the IDE.

With the up coming Eclipse milestone (Eclipse Juno M6), you can publish negation requirements. This means, RAP (and other components) can specify requirements that must not exist.  Negation requirements are specified by setting the cardinality (both min and max) to 0.  This is done using the p2.inf file.

In this case, our example feature wil not install if BadFeature is present.  Now, if I build and publish this and try to install, p2 will fail.

But, if I de-select the ‘BadFeature‘, then all is well again.

If you need negation requirements, please try this out when M6 is available and report bugs / feedback.

Historically, Yoxos managed your install for you. We would pre-compute all dependencies as to avoid p2 installation errors.  This is particularly important for Eclipse components with complicated dependency trees.  Unfortunately, this meant that you could not add your own p2 repositories to the mix.  I’m happy to announce that with Yoxos 5.5 you can now enable the p2 UI. This means you can use our catalogue of Eclipse plug-ins, or simply add your own.

With Yoxos, it’s easier than ever to launch standard Eclipse intalls or try new plugins. Simply download the Yoxos Launcher to get started.

As I hope everyone is aware, Juno (Coming Summer 2012) is an important release for Eclipse. It represents the transition from an Eclipse 3.x platform to 4.x.  If you plan on shipping products based on Eclipse Juno, make sure you start testing NOW!  This milestone has a number of noteworthy items including:

A great deal of static analysis checks
Null field checks

And more resource leak detection:

There are also some notable UI improvements such as editor navigation arrows:

Checkout the entire New and Noteworthy:
http://download.eclipse.org/eclipse/downloads/drops4/S-4.2M5-201201271145/eclipse-news-M5.html

Or better yet, download the milestone and TEST YOUR PLUGINS!
http://download.eclipse.org/eclipse/downloads/drops4/S-4.2M5-201201271145/index.php

While some teams are actively working on their components, other components are very mature and simply need some TLC from time-to-time.  There is certainly a number of things we could do with p2, but for the most part it works very well.  Pascal has been donating much of his personal time to p2 in order to give it the TLC and polish it needs. Pascal is pretty smart and 10 minutes of his time equates to an hour for most people .  However, it’s not fair that he spends all his free time tracking down problems in order for p2 to makes its contribution to the SDK.

I’m happy to say that I’ll be helping Pascal co-lead the p2 project.  There’s a few things I have planned including

1. Fixing a few recent problems on Java 7 Runtimes
2. Improving the performance of the UI
3. Looking at how we can reduce the size of our metadata (content.jar)

I’ll also be presenting some p2 related work at EclipseCon.  If you have questions, I try to hang around IRC and I’m also on twitter (@irbull).

Why Orion?

Before we can answer this, let’s look back 10 years.  A decade ago Eclipse had just shipped 1.0.  While many people saw Eclipse as a great Java IDE (which it is), Eclipse was also a universal tool platform.  Eventually Eclipse became a platform for Everything and Nothing In Particular, but in December 2001 it was a general purpose platform for development environments with Java Development as one such exemplary tool (C/C++ development was added shortly afterwards).  Many people attributed the success and quality of Eclipse to the fact that the developers used Eclipse for their day-to-day work, a concept known as eating your own dogfood. This model ensured that the quality of Eclipse remained high since any regressions would immediately be seen.

Fast-forward 10 years and we are starting to see many software tools moving to the web. Services such as GitHub, CloudBees, Cloudant, YouTrack, etc… reduce your IT overhead by moving many of your tools to 3rd party service providers, accessible via the web. Also, many of our applications are exposing web-based front ends and developers are relying on tools such as FireBug and other browser extensions.  Since most ‘coding’ still takes place on the desktop using tools like Eclipse or TextPad, developers are no longer using the tools they develop.

Eclipse Orion intends to change this.  Eclipse Orion is positioning itself as a Tooling Platform for the Web, on the Web.  If you’re currently building Web-Based software, then Orion will be of interest to you.

Is Orion Replacing Eclipse?

The aim of Orion is not to replace Eclipse.  Orion provides another tooling platform — this time for the web.  Not everyone is doing web development and not everyone wants their tools on the web.  However, if you are spending more of your time in a browser, Orion might be of interest.

Also, Orion is an entirely new code-base. This is not Eclipse running in a browser.

Getting Started

The easiest way to get started with Orion is to look at OrionHub.  OrionHub (http://orionhub.org) is a public beta server of Orion.  Anyone can request an account, but keep in mind that the workspaces are cleaned occasionally so there is no  guarantee that your data will be persisted.

1. Request an Account

Go to http://eclipse.org/orion to request an account.

2. Login to OrionHub

Go to http://orionhub.org and login. Once you’ve logged in, you can access you profile and associate other accounts if you wish.

3. Create your first project

There are a few helpful links across the top of the page. To create you first project, select the navigator and choose New Folder. You can also clone a project from a remote git repository if you choose.

4. Upload an existing project

Initializr allows you to create a bare-bones HTML 5 site, and download it as a zip file. This means you can get started on a new fancy web project without all the boilerplate setup.  I decided to download a bare-bone site from JavaScript InfoVis Toolkit for my example since I was interested in creating a graph based visualization. Using Orion, you can upload this zip file and start working immediately.

This this is on the web, you can review my code as I work:

http://orionhub.org/edit/edit.html#/file/ST/Jit/Examples/ForceDirected/example1.html

5. Launch a site

To test / debug your web application as you develop it, Orion allows you to launch a site containing the newly developed project. You can develop in one browser tab, and test (and debug) in another one. This paradigm means that all your tools are in one place.  To launch a site, choose the ‘Sites‘ link and Create Site.

You can map your project to this site.  In my case, I created a site called irbullvisualization. Feel free to access it at:
http://irbullvisualization.orionhub.org:8080/Jit/Examples/ForceDirected/example1.html

6. Share your project

By default, a Git repository is created for all projects on OrionHub.  Of course, this is just a local git repository (local to OrionHub), but you can easily add new remote references and push your projects around. You can commit changes using the Git Status Page:

And push your changes to remote hosts using the Repositories View:

Conclusion

The Eclipse Orion project is still in its infancy. Unlike the Eclipse project — which was opened sourced at the same time as its 1.0 release, the Orion project is still in its pre 1.0 stage. However, you can get involved with the project, tryout the beta at OrionHub.org or download your own Orion Server.

In my next article I’ll talk about Orion Plug-ins.

In both Nick’s and Mickael’s posts, I noticed a theme: all builds are the same. Of course when they are built, or the process by which the built artifacts are vetted may change, but the build process is the same for all build types: namely, take what’s in HEAD/Master/Trunk/Tip/Top/Main Branch, tag it and build it.

This isn’t the case for the Eclipse project. The Nightly builds are actually done differently from the integration, milestone, stable, and maintenance builds.

The build processes that Nick and Michael mentioned, assume that once something is in Master/Head, it’s ready to be released and the only other variable is release date.  The Eclipse process doesn’t assume this.  In fact, I can release a wad of changes the night before Juno ships and likely none of them will be in build.  This is because Eclipse requires explicit tagging of what you want built.

Here is how it works:

1. Development teams continually release stuff to master.  Each night master is built to ensure that nobody has introduced compile errors (or broke unit tests). This is not bleeding edge! This is not intended for anyone.  This is not similar to maven SNAPSHOTS.
2. When teams are happy with their work, they tag the bundle.
3. Integration builds happen weekly, and only what’s tagged will be built. Integration builds are similar to SNAPSHOTS, and can be consumed (if you want the most bleeding edge stuff).
4. This has recently changed, so instead of tagging each week, we merge (from master into ‘integration’). This means, what’s in master won’t necessarily be in a build each week.

I’m pretty sure I can hear the GitClub screaming feature branch, feature branch, feature branch. Why don’t you just use feature branches?

Please keep in mind:

1. Eclipse is over 10 years old, and predates Git.  Would you really do feature branches with CVS? (maybe)
2. The Eclipse build takes a while to complete:

• Let’s assume it takes 6 hours to build and run the tests (1/4 of a day).
• Let’s assume there are 10 teams (SWT, Debug, Workbench, PDE, JDT, UA, etc…)
• Let’s assume each team has 2 features on the go at all times: 20 feature branches
• Right now (for better or worse) a full Eclipse build, plus platform tests must run on the Eclipse build infrastructure
• So, if we had 20 feature branches that we had to build in sequence, it would take 5 days to build todays nightly
• Tomorrow’s nightly would start once that’s done!

Yes I realize some of those assumptions might be rather simplifying — maybe we could run the builds in parallel and off-load the costs to the hardware, but having a central build of 20 feature branches is still not feasible.  Also, some teams would likely want to combined builds (now build the SWT + Workbench feature branch together).

I know some people will head down the path of build restructuring (completely refactor the Eclipse build so developers can run them locally, thus removing the necessity for a centralized builds). We’ve heard this before many times.  Instead of suggesting this, sponsoring the effort (with money + people power) would be more helpful.  Also remember that Eclipse has successfully shipped on-time for the pat 10 years.  So, if you really want the team to change their process to the development flavour of the week, be prepared to show some evidence that process XYZ is better.

This was not meant to start a development war, but rather explain a bit about how the Eclipse build process works.  For better or worse, it’s what we have.

BTW, what do others do? Does everyone use feature branches and assume what’s in Master is ready? What did you do before Git (did you use branches for development in CVS/SVN)?