A place for committers to roam together

Among others, two topics regularly come back in various forums
- diversity in the participation of a project
- common components / code duplication

In my opinion, one of the reason for these problems is the absence of communication / communication medium between the actual doers, the committers, thus leaving each of them ignorant of what others are doing and the problems they are facing, solving, etc.

What I would like to have is a place for committers to be able to ask technical questions, exchange ideas, etc. thus giving them an opportunity to discover common interests and help building a stronger sense of fellowship.

Is this place eclipse.org-committers@eclipse.org mailing list? Anyway if such a place exist, we need to make sure everyone knows about it and is not shy about sharing and if it is not we should experiment with it. Please comment on bug 205572.

The equinox provisioning effort now has a name

This afternoon team meeting gave the "equinox provisioning effort" the cool snappy name of

P2

Yes, you read it right the letter P, then the number 2. It can stands for the followings in no particular order:
- Provisioning Platform
- Provisioning Partout (partout is the french word for everywhere)
- Pascal's Provisioning (hey, why not? We do have the "Ed Merks Framework")
- Provisioning, the 2nd generation

The bundles and packages will be renamed right after M2 has been delivered.

The motivations behind this renaming can be found at http://wiki.eclipse.org/Equinox_Provisioning_Naming.

New PDE ad

This ad from a phone company, could well be the new ad and motto for PDE :-)

iPhone and Eclipse

iPhone may not get Java, but Eclipse gets the iPhone. Yes, Eclipse gets an IDE to "increase iPhone developement productivity". I don't know if this is the official SDK (my guess is no), but anyway I found this pretty cool. See http://www.aptana.com/iphone/

Europa + PDT + Subversive == happy wife

Yes this is a weird equation, but I can tell you that since I set my wife up with PDT and a few components from Europa, she is the happiest PHP developer around.
To my biggest surprise setting her up with an IDE doing PHP, subversion and remote exploration (these were her requirements) was really easy and the result worked well.

Here are the steps that I followed:

• Downloaded the eclipse SDK (who knows she may want to do plugin
  developement :-))
• Added the following URL to the list of update sites (this is because
  subversive and PDT are not part of Europa)
- http://www.polarion.org/projects/subversive/download/update-site/
- http://download.eclipse.org/tools/pdt/updates/

• Selected the previously added site and the Europa one, clicked next
• Once presented with the list of things to installed I picked:
- PDT Features
- Subversive SVN Team provider
- Remote Access and Device Development > Remote System Explorer End-User Runtime
- Remote Access and Device Development > Target Management Terminal

• Clicked "select required", clicked a few times next, accepted the license and after a few moments of download I was able to restart and get access to all these new functionality.

To be honest, and you know that I like to criticize, I was impressed by relative simplicity of the install and the maturity/quality of the components that I got. Currently my favorite one still is the remote system explorer.

Next step, setting her up with Mylyn for managing bugs.

Helpwanted

Marking bugs as "helpwanted" is fine and does capture the essence of the desire from a committer standpoint. However I believe this is not enough to engage with the community. Why? Because the codebase is huge and without knowledge of where to start, there is almost no chance for someone to succesfully help.
So what? If you, committer, really want help, you should give a few entry points in the code where to start investigating the problem and if you, community member, really want to help you should ask for those entry points.
In PDE/Build we have done that for a few things that we did not had cycle to fix and the feedback has been great. So why don't you try and see if it helps.

Dream or reality?

I know that I should not do software related stuffs until the last minute before going to bed, or otherwise I have a tormented night.
Unfortunately yesterday night I did not respect that... but instead of having a nightmare and I ended up having the sweet dream that fed up by the limitations of java, the eclipse team would set on a journey to develop java extensions making the development faster, the code smaller and faster, the extensibility easier, etc. It would contain blocks, partial classes, extension methods, ... and our productivity would be so boosted that we could release in February instead of June. Unfortunately that was only a dream but I swear that I'll read again those C# 3, Smalltalk, Scala or Traits papers before going to bed.
Should we make this dream reality?

Ps: By the way, in my dreams the extensions were producing regular java byte codes.

A fine polish item for the community

We (the equinox team), after a lengthy discussion, moved out of our bucket the bug 155897 into the UI one. This bug is about finding a way to expose to the end user which bundles are not resolved and why. Unfortunately the UI team is just overbooked. Therefore if you want to see this bug fixed, it is the right moment to step up and provide a patch for inclusion in M7.

Why can / should this item be addressed by the community?

• It is simple


• It is self contained, therefore not requiring an extensive knowledge about the system and thus limiting the risk of instability


• You will get gratitude from committers and other users.

So if you want to give this problem a try, please declare your interest in the bug report. Thanks in advance.

ORBIT is ready for prime time

Orbit is now ready for prime-time. However don't ask us to put in Orbit your favorite jar because Orbit is *not* a super general repository. As per the project charter you will only find in here the libraries that other eclipse projects need. In fact the creation of orbit stemmed from the problem experienced in Callisto where each projects had their own copy of common.logging and the like which created various problems.

So to summarize, if you are an eclipse project using third party libraries and you want to maintain your libraries in a central place, then Orbit is for you (platform, wtp, tptp and a few other projects already do that).

Now on some rectification from Alex post :
- "so no GPL or LGPL is allowed.": Of course, this is true of eclipse in general because of license compatibility issues.
- "and the bundles have a date qualifier (which then changes between the builds, even if the actual version of Xerces and the codebase remains the same)". Wrong. Orbit uses the same practice than the eclipse SDK when it comes to managing qualifiers. The qualifier is generated from the CVS tag and the output will not change from one build to another if the content of the project has not changed. For example, the javax.servlet bundle in orbit  S200703161546 , is the same than javax.servlet in orbit S200702082257.

Paving the road to a new update manager, the first block

I've finally sent the annoucement email mentionning the creation of the provisioning incubator. I'm disappointed that I could not sent it earlier to give people more time to see what is going on before eclipsecon, but the last minute hacking for our "cool stuffs in equinox" demo (wednesday morning 10am) lasted longer than I expected :-) Oh well....

Regrets aside, I'm really exited because this is a new start and I really hope that we will get some strong and valuable involvement/contribution from the community and also cross fertilization with EPP and Maya (hope to see some of those guys become committers on the provisioning since it will influence a lot what they are doing). In fact I personnaly believe it is the perfect opportunity since we are starting from scratch and all in the open. Ok it is not perfectly from scratch because I have already committed some code, but this is more a starting point for discussions and directions rather than being the final answer.

So now I'm off to finish my suitcase and other slides, and I hope to see you at the "provisioning, an update on update" bof wednesday night.

On the road to a new update manager

In order to start paving the road to a new update manager, a provisioning work area is being put to vote on the equinox incubator. The proposal can be found here; and you can vote on the equinox-dev mailing list.

Multiple versions of the same bundle during the build

Following the theme "pde to support multiple versions", I've just released the support for multiple versions in PDE Build.
This means that you can now build a product / feature made of multiple versions of the same bundle (given that they are not marked singleton).

How do you do that:
- In the feature.xml, identify the plugin and replace the 0.0.0 by the first three segments of the desired version followed by the string "qualifier". Example:
    <plugin id="org.junit" version="3.8.1.qualifier" ... />
    <plugin id="org.junit" version="4.1.0.qualifier" ... />

- In the map file, identify the plugin and add the first three segments of the version before the '=' sign (don't forget the comma)
    plugin@junit,3.8.1=v20070301.....
    plugin@junit,4.1.0=v20070301.....

Of course, if you don't use multiple versions you don't have to do anything new.