Eclipse-based applications as standard mac application bundle

It's not every day that a 5 digits bug number get's fixed in Eclipse*, so I'm happy to report that the long standing bug 57349 is now fixed in Juno (Eclipse 3.8 / 4.2). It means that you can now deliver eclipse-based applications as mac os x bundled applications.

New layout

For an end user, the biggest change brought here is that the application is now an opaque entity and it has an icon. See screenshot below of the same application to compare.


Now in the details, the new layout pictured on the left mainly differs from the legacy one on the right by two things:

• the top level folder is now suffixed with .app; thus making the application an opaque entity that requires a special user action to navigate into it (this is also why the left picture does not show the top level folder)
• the actual launcher included in the Contents folder is included as a child of the top level folder where as in the past it was in a folder whose name was the name of the launcher (e.g. myRCP in the example).

How do you enable this new layout?

1. Make sure the application you are building uses p2 included in Juno
2. Move your build environment to use PDE Build from Juno, or Tycho 0.15.
      This will cause the additional metadata necessary to support this new layout to be generated.
3. When you invoke the p2.director (the one from Juno) to create your application simply suffix the install folder with .app and let the magic happen. If you don't want to keep the legacy shape, don't use the .app suffix. Here is an example of command line: ./eclipse -application org.eclipse.equinox.p2.director -installIU <iufortheproduct> -destination Applications/myCool.app -profile <somename> -repository <therepotoinstalltheproductfrom>

Note to tycho users

Tycho 0.15 (still in snapshot at the time of writing this post) generates the appropriate metadata and p2 repo, but the support to create an installation and archive with the correct layout is not yet released (bug 378021). To obtain the desired shape you can either call the p2 director as mentioned above, or use the workaround provided in bug 378021.

Note to PDE build users

PDE build generates the appropriate metadata and p2 repo, but it will not create an installation and archive with the correct layout. To obtain the desired shape you will have to manually invoke the p2 director as indicated above.

And to conclude I would like to mention that this work has been sponsored by Manumitting Technologies. * Well actually, at this point I count 28 5 digits bug number fixed in Juno and one 4 digits bug number - bug 9503

Sharing your plug-ins easy as 1-2-3

"Hey, this is a cool plug-in, where did you get it from?" is a question that I hear quite often and to which the answers most people provide are a google search, a vague reference to the eclipse market place, or a lengthy email with links to p2 repos and sentences to explain which element should be selected. With any of these solutions there is a lot place for errors, especially if you are trying to have the same version.

Since Indigo, p2 provides the ability to answer this question in 3 easy steps using the import / export functionality. Let's see how this works

Step 1 - Create a description file

Using the File > Export > Install > "Installed Software Items to File" wizard, select the plug-ins that you want to share, and save these to a description file.
In the screenshot below I've decided to share both the Groovy for Eclipse plugin and the Remote System Explorer plugin.

Step 2 - Share the description file 

The description file created, share it using your favourite social media, or just simply email.

Step 3 - Import the description file 

Upon reception of the description file, go to File > Import > Install > "Install Software Items from File" wizard, pick the file to install from and just follow the steps. You may also want to uncheck the "install latest version of selected software". This will cause the selected items to be installed from the remote location.

Conclusion

This showed how easy it is to share details of your install with others. It works well for ad-hoc sharing. For anything more complex like keeping in sync all the members of a team, I would instead recommend the usage of Yoxos from EclipseSource (I am *not* affiliated with EclipseSource) that offers a solution dedicated to solving this problem.

More on p2 and OBR

When I set out to write my previous blog post about why not OBR, the intent was to give, with a catchy title, an historical perspective on p2 (thus the recent title update) but also to answer people who have been asking for years this question

(and yesterday night another one of those came in).

The point was not to do a comparison of p2 and OBR as they are today, and especially not to claim that OBR is not good today. Both technologies have pros and cons. My statements about OBR were a reflection of the situation as it was ~5 years ago. To be honest, I have not been following the recent development on the spec, just heard some rumours.

When I wrote the previous post, I also wrote two additional paragraphs that I had not published. One was about our absence of involvement in the spec process and one about going forward. So here they are:

Could we have collaborated on the spec and implementation?

Maybe, but at the time the interest around OBR was rather low at the OSGi alliance, we did not had the bandwidth to drive improvements to the specification since we were focusing on shipping running software (the first release may not have been the best thing, I agree), and my management at the time was not up for the work, distraction, and frustration it could have represented. It needs to be remembered that some of us had been involved in the OSGi spec process to drive changes (adding fragments, bsn, require bundle, etc. Yes all these mostly were driven by the equinox team) and it had been a painful experience that left the people involved with scars, and made some of them the ongoing target of criticisms because of the changes they pushed for.

A couple years later (~2009?), OBR got brought back the forefront in the context of the OSGi Enterprise Expert Group. At this point, I have been involved in the spec work even to a point where I was the lead. Because of my lack of time, and the problems scoping the work, my contributions have been limited and then I stopped being involved as Sonatype withdrew from the OSGi alliance.

Is there a way forward?

Until a publicly visible draft of OBR is available, I can't provide a definitive answer. However implementing OBR on top of p2 has definitely been discussed several times and is not out of question especially if the specification stays focused on providing a resolver API and a repository API.

Now time, energy and contribution will tell...

PS: there are things that need to be corrected from Neil's post, but my other commitments are calling so it will have to wait.

p2 at EclipseCon 2011

This year again, there will be plenty of opportunity to learn and discuss p2 at EclipseCon.

There are four talks:

* p2, your savior or your achilles heel? Everything an Eclipse team needs to know about p2

* Discovering the p2 API's

* Updates in the micro space

* Raising the Eclipse Provisioning to the Clouds

One BOF:

* Fireside chat on p2

And a lot of p2 committers and enthusiasts ready to discuss anything :)

See you there!

p2 API presentation posted

The slides of my EclipseCon talk on the p2 API are now available on slideshare: http://www.slideshare.net/PascalRapicault/discovering-the-p2-api

Enjoy!

More p2 stuffs

Given yesterday's very busy p2 BOF, I have decided to organize another one tonight at 8:15 PM so we could continue the conversations we had started and even more.

Your p2 guide at eclipsecon

You can find below all the p2 related events at eclipsecon. Some of them are really focused on p2 while others are describing their usage of p2. Enjoy!

Monday:

From build to assembly to deployment: Using p2 to facilitate agile software development.

Use EMF and Equinox p2 to manage device development environment

Discovering the p2 API

Introduction to Eclipse b3

Building with Buckminster

Tuesday:

Managing P2 Repositories and Repository Interoperability with Nexus Professional

Eclipse in the Enterprise: Lessons from Google

p2 BOF

Wednesday:

Simplifying update and extension install for RCP applications

Moving on

At the end of the week I will be leaving IBM / OTI. I have truly been honored to be part of the Eclipse Platform team and through this experience redefine the IDE, deliver RCP, shape up Java componentry and perform many other stunts. It has been 7 fantastic years.

As hard as it is to leave, I'm very excited about the opportunity to join Sonatype [1] because they have an exciting portfolio of products [2] and a commitment to open source (Maven, m2eclipse, ...). Therefore I will continue to be heavily involved in the Eclipse community and provide leadership for the p2 project. I look forward to being a part of the Eclipse team from a new perspective and have no doubt that I will run into other members of the Eclipse team in the future.

[1] http://www.sonatype.com

[2] http://www.sonatype.com/people/2010/01/next-generation-maven-development-stack/

Project diversity

When a project is not diverse, I find it a bit too easy to blame it on the actual company who started the project, the people steering it or how inviting to contribution the project is. Though I don't want to underplay those points, I argue that there are other things that matter:

Relevance of the project: maybe the topic of your project does not interest anyone but you or your company. Sorry.

Timing of the project: you can have the coolest technology, if you are too late or too early, it will be harder to excite the crowds.

Pace of the project: the project goes too fast for others to follow or committers to accept external contributions (e.g. the pace imposed by the company's internal schedule is such that it does not allow for the external contributions to be considered by committers). Conversely The project goes too slow for anyone to be willing to bet on it.

Quality of the project: the project is running well, builds are regular, deliverables are on schedule, bugs and enhancements are dealt with quickly. The community gets what it needs, why should it care?

Amount of code: is there enough code to show the direction of the project. People are happy to work on a project but I think they feel more conformable starting from a working code base than a whiteboard.

Now if I relate that to p2, where we have a diverse community of contributors (IBM, Cloudsmith, EclipseSource, University of Lille-Artois) I think we have been lucky because p2 came at the right time, solving a real pain point. Indeed, the same year we announced p2 (EclipseCon 2007), there was at least 5 talks on how to manage Eclipse, and Cisco announced the creation of the Mayinstall project. As for code goes, we already had a functional prototype and we continued developing it in the open, holding public calls every week. All that said, I believe that p2 would still be a single-company-developed project, if the companies who joined the force had not had a business interest to contribute.

Where does leave us? Luck. I would argue that much like for any other success, the success and diversity of a project just happen to be a combination of preparation and timing with of course a zest of hard-work and persistence.

Nesting categories

A recurring topic around categorization in p2 is the ability to nest categories.


Like for the categorization of bundles, the trick consists in using the eclipse feature editor to express the dependencies and thus construct the desired nesting.

Steps:

First phase, creation of the inner category.

1. Create a feature project called InnerCategory1. In our example this will be the feature containing the elements to be shown categorized.
2. Turn this feature into a category by creating a p2.inf and filling it with:
   properties.1.name=org.eclipse.equinox.p2.type.category
   properties.1.value=true
3. Remove everything from the build.properties of the feature.
4. Use the features and plug-ins tab of the feature editor to add content to be categorized.

This concludes the creation of the inner category. The following steps create the "top level" category.

1. Create a feature project called TopLevelCategory
2. Turn this feature into a category creating a p2.inf and filling it with:
   properties.1.name=org.eclipse.equinox.p2.type.category
   properties.1.value=true
3. Remove everything from the build.properties of the feature.
4. In the features tab of the editor, add InnerCategory1

5. Export the top level feature enabling metadata generation

You can find the code of this example on the wiki.

Happy categorization, happy provisioning!

Categorizing plug-ins

Despite what is commonly believed and what I have repeated to several occasions, p2 does allow for the installation of anything, anything being for example just bundles. It just happens that today, with the practices adopted over the years, features have grown to be the primary way of delivering features.

I'm now showing how to create a p2 repository whose category refers to bundles.

Steps:

1. Create a new feature project. This adds the category property to the installable unit, thus allowing the UI to recognize the feature as a category to be displayed.
2. Create a file named p2.inf in the feature project and paste in the following two lines:
   properties.1.name=org.eclipse.equinox.p2.type.category
   properties.1.value=true
   
3. Include the plug-ins you want to see being categorized. This is where you define what goes in the category. Each entry in the plug-ins list will be shown under the category.
   
   
   
4. Remove everything from the build.properties included in the feature. This causes PDE to not generate a feature.jar.
5. Export the feature enabling metadata generation.
   

You can find a zip of this example on the wiki.

Happy categorization, happy provisioning!

p2 community contribution

If you are interested in contributing to p2 during the Helios (3.6.) cycle, please add your areas of interest on the wiki. It can either be new functionalities as well as things that you would like to see improved.

Expressing your desire early will allow for other contributors to potentially join you and for the current set of p2 committers to plan for coming contributions.

Thanks in advance.

p2 EclipseCon 09 slides posted

I have just posted the slides for the talk and tutorial I gave on p2 at EclispeCon 2009.

The talk goes over the p2 functionalities from a runtime perspective and the build / dev time aspects.

The tutorial covers all the major aspects of p2. It ranges from the simple usage of product delivery to an in-depth presentation of the p2 concepts.

Enjoy!

p2 metadata and resolution detailed

Daniel Le Berre (one of the author of SAT4J) and myself have a paper accepted to IWOCE. The paper focuses on the dependency management aspect of p2. It describes the metadata used to express dependencies, the overall functioning of our resolver and a description of our propositional constraints based encoding. To conclude we describe the challenges to address in future releases.

The paper is available at http://www.cril.univ-artois.fr/spip/publications/iwoce907-leberre.pdf

OSGi DevCon Europe 2009 slides

I have finally uploaded the slides of my OSGi DevCon talk on slideshare. The presentation goes over some of the p2 concepts and talks for the first time about 3 different ways to setup p2 depending on the constraints of your environment: milli, micro, nano.

p2, modular provisioning for OSGi

View more presentations from IBM.

p2 at OSGi DevCon Europe / Jazoon

If everything goes well (understand my travel request gets approved), I will be presenting p2 at OSGi DevCon Europe / Jazoon in Zurich on June 22nd.

If you want to meet to chat about p2, build or OSGi, please drop me a note (esp. if you are an IBM Rational customer) and we will schedule something during my short visit in Switzerland.

p2, call for community testing

During 3.5, a release put under the theme of robustness for our team, p2 went through a lot of changes: new UI, improved error reporting, more robust downloads, improved transactionality of the installation,.. the list is endless. About 900 bugs have been closed.

However, in order to avoid releasing 3.5 with big issues (which we think/hope we don't have), I'm calling out to you to try out p2 by downloading RC1 and give it a spin and a hard time, and report any problem in the p2 component here.

Thanks in advance.

p2 content at EclipseCon

This year is a good year for p2 content at EclipseCon. Among the 26 sessions that got submitted and mentioned p2 in their abstract 13 of them have been accepted.

The p2 fest starts with our tutorial on p2, Monday afternoon. However I'm sure that Andrew N. will have discussed p2 integration in the build in the context of the Common builder tutorial in the morning. Also Monday afternoon is Kai's RCP tutorial that seems to describe the usage of p2 into an RCP application

Then on Tuesday the party continues with Jeff's talk on the Runtime (r)evolution which I'm sure will mention p2 and also with Richard and Markus who have been busily creating p2-enabled Galileo packages.

However Wednesday is "the" p2 day with:

1. Henrik and Thomas talk about Buckminster and p2
2. Darin and zx talk on PDE
3. My talk on what's new in p2
4. The short talk session on web-centric technology the newly p2-rebased Yoxos and the EPP Wizard (but I'm not sure how much p2 there will be in those talk).
5. The short talk session on runtime deployment where server side provisioning with p2 and the complexity of versioning in a provisioned world are discussed.
6. And finally the p2 BOF.

I would be surprised if by the end of the day I was still able to talk.

Have a safe trip and see you there.

Reworked p2 workflows

I'm happy to announce that last week I-build (I20081014) features reworked p2 workflows. It is currently work in progress and more will be done in 3.5.
What is particularly interesting with this effort, is that it is the result of feedback directly gathered from the community through bugs, definition of personas [1], and meeting with the eclipse UI workgroup [2]. A truly open process and interesting way to design a UI with people from all backgrounds with diametrically opposite ideas on how it should look.
It's not too late to contribute ideas for the evolution of the workflows in 3.5 As usual, any feedback can be given through bugzilla (RT > equinox > p2, be careful we moved), or on the p2-dev mailling list.

[1] http://wiki.eclipse.org/Equinox_p2_UI_Use_Cases
[2] http://wiki.eclipse.org/Equinox_p2_User_Interface
Reworked p2 workflows.