Since I don't have enough energy left to also write a thousand words, here is just an overview picture of the Eclipse SDK 4.0 Early Adopter Release that we shipped today. I hope you find it useful.
Wednesday, July 28, 2010
Monday, July 12, 2010
Reminder to submit proposals to ESE 2010
The submission system for Eclipse Summit Europe has been open for a while now, and the deadline is approaching. Now that the Helios release train has successfully shipped1, it is time to think about talks or tutorials that you want to submit.
The main topics for ESE 2010 will be Embedded, Modeling, Runtime, and e4. If you have something to say or teach about these subjects, then great. But don't be discouraged if you have a proposal that doesn't quite fit in these categories. Make a submission anyway.
Eclipse Summit Europe is a great conference, at a really nice location. To make it a success, we need quality content from the Eclipse community, in other words: from you!
1 What a weird image, a train that is shipping. It's been done before, though :-)
Saturday, March 13, 2010
Announcing the e4-Rover Mars Challenge
For the last couple of weeks, a few people from the e4 team and NASA JPL have been busy working on a cool programming contest to introduce e4 to the EclipseCon attendees, and to encourage them to try out e4 and learn about it. (See below for acknowledgments.)
The idea is to drive a LEGO rover to collect points - your mission is to align the robot's on-board "instruments" with martian "rocks" in an arena. There are two ways to win - collect the most points to win a Lego Mindstorms NXT 2.0 set, or write the best e4-based client to win a Lego Mindstorms and a trip to the NASA robotics lab in Los Angeles. Other prizes include credits for Amazon Web Services and T-Shirts.
The architecture of the game system is interesting - the Lego robot executes commands that are sent to it from a local machine via bluetooth. The clients won't communicate with this local machine directly though - to make everything scalable, data about the state of the game, and an overhead view of the arena and the rover is made available using Amazon Web Services. We have an Equinox-based server on EC2, and are using S3 for making data available in a scalable way.
We provide a basic e4-based client, with a joystick-like way to control the rover. If you want to win the grand prize, you'll have to improve the client to make it look better and operate the robot more efficiently. We basically want people to hack the client to beat the game. To help you do this, we have started a tutorial (which we'll refine and expand over the next few days) and a FAQ. We will also add some more comments to the client code, and perhaps tweak the code a little bit, so make sure you check if there are newer versions of the source code available.
To give people a head start we are making the current source code for the client available today. You can download the code now, run the client but you can't actually control the robot. You need a hash key to control the robot and those will only be given out at EclipseCon. What you will be able to do is watch us have some fun playing with the robot, erm, I mean, perform more testing, because the client includes a webcam view of the robot. More detailed instructions are available on the contest web pages.
I have been playing with the robot for the last week. For a little while, I was at the top of the high score list, but since then others have gotten much better. I'll have to end the blog post here to do some more testing. ;-)
Driving the rover is a lot of fun! It's only a week or so until you can play too, at EclipseCon.
P.S. Credit for the idea goes to Jeff Norris, who will be presenting a keynote on Wednesday. Khawaja, Victor, and Mark from Jeff's team worked on the hardware and the server side, and Brian de Alwis, Benjamin Cabe and myself wrote the simple e4 based client. Lars Vogel is helping with the documentation. Ian Skerrett from the Eclipse Foundation is coordinating everything, Lynn is going to help run the contest at EclipseCon, and a good number of e4 committers have been recruited as volunteers.
The idea is to drive a LEGO rover to collect points - your mission is to align the robot's on-board "instruments" with martian "rocks" in an arena. There are two ways to win - collect the most points to win a Lego Mindstorms NXT 2.0 set, or write the best e4-based client to win a Lego Mindstorms and a trip to the NASA robotics lab in Los Angeles. Other prizes include credits for Amazon Web Services and T-Shirts.
The architecture of the game system is interesting - the Lego robot executes commands that are sent to it from a local machine via bluetooth. The clients won't communicate with this local machine directly though - to make everything scalable, data about the state of the game, and an overhead view of the arena and the rover is made available using Amazon Web Services. We have an Equinox-based server on EC2, and are using S3 for making data available in a scalable way.
We provide a basic e4-based client, with a joystick-like way to control the rover. If you want to win the grand prize, you'll have to improve the client to make it look better and operate the robot more efficiently. We basically want people to hack the client to beat the game. To help you do this, we have started a tutorial (which we'll refine and expand over the next few days) and a FAQ. We will also add some more comments to the client code, and perhaps tweak the code a little bit, so make sure you check if there are newer versions of the source code available.
To give people a head start we are making the current source code for the client available today. You can download the code now, run the client but you can't actually control the robot. You need a hash key to control the robot and those will only be given out at EclipseCon. What you will be able to do is watch us have some fun playing with the robot, erm, I mean, perform more testing, because the client includes a webcam view of the robot. More detailed instructions are available on the contest web pages.
I have been playing with the robot for the last week. For a little while, I was at the top of the high score list, but since then others have gotten much better. I'll have to end the blog post here to do some more testing. ;-)
Driving the rover is a lot of fun! It's only a week or so until you can play too, at EclipseCon.
P.S. Credit for the idea goes to Jeff Norris, who will be presenting a keynote on Wednesday. Khawaja, Victor, and Mark from Jeff's team worked on the hardware and the server side, and Brian de Alwis, Benjamin Cabe and myself wrote the simple e4 based client. Lars Vogel is helping with the documentation. Ian Skerrett from the Eclipse Foundation is coordinating everything, Lynn is going to help run the contest at EclipseCon, and a good number of e4 committers have been recruited as volunteers.
Tuesday, February 23, 2010
Eclipse Board Election Facts (2010 edition)
Rather than explaining why you should vote for me :-), I thought it would be useful to summarize the key election facts:
- You are voting for a one-year term starting April 2010. Voting is open as of yesterday, for three weeks until March 12, 3 pm Eastern time. Check out the committer candidates and their vision statements.
- To vote, check if you received an email from emo@eclipse.org on Feb 19, 2009. It contains the URL for voting, as well as the required voting password. If you haven't received a voting password, you are probably not (yet) an Eclipse member, and have to sign the membership agreement first. To understand why this is required, read this page, then read this page to make sure you fill out the form correctly. No voting privileges without signing the form!
- The Board will have 20 directors, as follows:
- Fourteen directors for the strategic members, one seat per member.
- Three directors from "sustaining members". There are six candidates on which sustaining members (companies) get to vote.
- Three directors representing the committers. There are five committer candidates.
Monday, February 08, 2010
Suffrage
At the risk of playing with words whose connotations I don't fully understand... Eclipse committers have to suffer - a little bit - to be enfranchised. I mean, to get the right to vote in the 2010 Eclipse board member elections, which begin two weeks from today, on February 22, 2010.
If you are an individual (not employed by a member company) committer: Please click here, and sign and send the membership agreement to the Eclipse Foundation. This will enable you to vote in the upcoming board member elections. There is no cost, and as an added bonus, the Eclipse Foundation is now sending really nice thank-you e-mails to those individual committers who become members.
Why should you do that? Let me try to explain with a diagram:
Here is the same information in text form, copied from the election process web page:
That seems a little bit weird, but it sort of makes sense considering the situation back when the rules were made: IBM had way more Eclipse committers than everybody else, and there was a risk that they would determine the committer representatives, who then could be seen as voting in favour of IBM - leading to an imbalance at the board of directors. So when you think about it, the rules ensure that the committer representatives election is truly independent of any potential company interests.
So, to repeat, if you are an individual (not employed by a member company) committer: Please click here, and sign and send the membership agreement to the Eclipse Foundation. It's free (of charge), it will enable you to vote in the upcoming board member elections, and as an added bonus, the Eclipse Foundation is now sending really nice thank-you e-mails to those individual committers who become members.
More votes mean more weight for the committer representatives on the Eclipse Board of Directors. And if you are an individual committer, your vote weighs a lot!
Word definitions.
If you are an individual (not employed by a member company) committer: Please click here, and sign and send the membership agreement to the Eclipse Foundation. This will enable you to vote in the upcoming board member elections. There is no cost, and as an added bonus, the Eclipse Foundation is now sending really nice thank-you e-mails to those individual committers who become members.
Why should you do that? Let me try to explain with a diagram:
Here is the same information in text form, copied from the election process web page:
- Each Committer Member gets one vote. Note that committers who are employees of Member companies have all the rights and privileges (including voting) of a Committer Member.
- Individual committers must join the Eclipse Foundation as Committer Members by signing the Membership Agreement in order to be allowed to vote.
- All committers who are employees of a single company have their votes collapsed into a single vote in the committer elections.
That seems a little bit weird, but it sort of makes sense considering the situation back when the rules were made: IBM had way more Eclipse committers than everybody else, and there was a risk that they would determine the committer representatives, who then could be seen as voting in favour of IBM - leading to an imbalance at the board of directors. So when you think about it, the rules ensure that the committer representatives election is truly independent of any potential company interests.
So, to repeat, if you are an individual (not employed by a member company) committer: Please click here, and sign and send the membership agreement to the Eclipse Foundation. It's free (of charge), it will enable you to vote in the upcoming board member elections, and as an added bonus, the Eclipse Foundation is now sending really nice thank-you e-mails to those individual committers who become members.
More votes mean more weight for the committer representatives on the Eclipse Board of Directors. And if you are an individual committer, your vote weighs a lot!
Word definitions.
Suffrage (from the Latin suffragium, meaning "voting tablet", and figuratively "right to vote", and originally a term for the pastern bone used to cast votes) is the civil right to vote, or the exercise of that right.
...
Where Universal suffrage exists, the right to vote is not restricted by race, gender, belief, wealth or social status. It typically does not extend a right to vote to all residents of a region; distinctions are frequently made in regard to citizenship, age, and occasionally mental capacity or criminal convictions.
Thursday, February 04, 2010
Can we turn e4 into an orange?
Let me write a quick response to Elias' thought-provoking post. I hope there will be other (and not so quick) responses as well - it is important to step back every now and then to assess whether we are going in the right direction. But for now, I didn't want to let the issues he raises without an answer from the e4 team. The question for me is, how can we turn e4 into a juicy and sweet lemon? ;-)
Killer feature: I fully agree that support for styling and skinning is not going to be enough of a killer feature to convince everybody that it is worth stepping up to e4. What could be other killer features? To be honest, I am not sure. I would be interested in hearing opinions on this - please leave comments!
Download size: The 230 MB are easy to explain - this download includes the 3.x Eclipse SDK (167 MB), the EMF SDK (27 MB), some parts of WTP, GEF, and other bits and pieces. If you just look at the e4 bundles, they amount to just over 2 MB. The dependencies of the core e4 bundles (a subset of those 2 MB) are SWT, JFace, Equinox, and the EMF core runtime. It could always be smaller, but the 230 MB are just the wrong number to look at. Unless you are interested in the footprint of e4 + compatibility layer + everything from the current Eclipse SDK, but clearly it is not the long-term goal of e4 to always ship with everything from 3.x.
Different: This takes a little longer to explain, but luckily a good response already existed, in the form of John Arthorne's argumentation from bug 300099 comment 4 (I made minor adjustments to make it fit better into this blog post):
The purpose of injection was to make it easier to obtain services in the general case, as well as to decouple of service user from knowing or caring about who provided the service. I'll offer a couple of examples that I've taken from the existing 3.x code (all from the current ResourceNavigator.java in 3.6):
1) I want to print a message on the status line. In 3.x this is:
getViewSite().getActionBars().getStatusLineManager().setMessage(msg);
In e4 this should be:
@Inject
IStatusLineManager statusLine;
...
statusLine.setMessage(msg);
2) I want to get the selected resources:
like:
@Inject
IWorkbenchHelpSystem helpSystem;
...
helpSystem.setHelp(viewer.getControl(), getHelpContextId());
The end result is simpler code, but it also removes a mass of assumptions that
the client previously had to make, about what their containment structure
looked like and where specific services came from. I think we sometimes take
for granted how difficult it can be for clients in 3.x to figure out where to
get particular service from.
Having said all that, we have probably gone too far down the
"non-specification" route in e4. I think it is essential that we provide
interfaces containing specification of things clients must implement (e.g., you
need a doSave() method for parts that are to be used as editors). We can make
the interface optional if we want, but there has to be somewhere where we
specify the behavior expected/required for clients. To me this specification of
expected behavior for clients is orthogonal to service injection so I hope that
we can have both.
1) I want to print a message on the status line. In 3.x this is:
getViewSite().getActionBars().getStatusLineManager().setMessage(msg);
In e4 this should be:
@Inject
IStatusLineManager statusLine;
...
statusLine.setMessage(msg);
2) I want to get the selected resources:
ArrayList list = new ArrayList();I'm not sure how we handle multi-selection in e4, but this should be something
if (selection instanceof IStructuredSelection) {
IStructuredSelection ssel = (IStructuredSelection) selection;
for (Iterator i = ssel.iterator(); i.hasNext();) {
Object o = i.next();
IResource resource = null;
if (o instanceof IResource) {
resource = (IResource) o;
} else {
if (o instanceof IAdaptable) {
resource = (IResource) ((IAdaptable) o)
.getAdapter(IResource.class);
}
}
if (resource != null) {
list.add(resource);
}
}
}
return new StructuredSelection(list);
like:
@Inject3) I want to associate a help context with my control
public void setSelection(@Named("selection") List<IResource> selection) {
selectedResources = selection;
}
getSite().getWorkbenchWindow().getWorkbench().getHelpSystem().setHelp(In e4 this should be something like:
viewer.getControl(), getHelpContextId());
@Inject
IWorkbenchHelpSystem helpSystem;
...
helpSystem.setHelp(viewer.getControl(), getHelpContextId());
The end result is simpler code, but it also removes a mass of assumptions that
the client previously had to make, about what their containment structure
looked like and where specific services came from. I think we sometimes take
for granted how difficult it can be for clients in 3.x to figure out where to
get particular service from.
Having said all that, we have probably gone too far down the
"non-specification" route in e4. I think it is essential that we provide
interfaces containing specification of things clients must implement (e.g., you
need a doSave() method for parts that are to be used as editors). We can make
the interface optional if we want, but there has to be somewhere where we
specify the behavior expected/required for clients. To me this specification of
expected behavior for clients is orthogonal to service injection so I hope that
we can have both.
Wednesday, February 03, 2010
Sometimes, bug triage is no fun
Here is how I intend to respond to a private email that I received today, about a bug that was filed yesterday. How would you respond in a similar situation?
Hi [X],
Thank you for reporting a problem with Eclipse. But - and maybe it's just me - the private email you sent today comes across as demanding. You are asking us to help you quickly, without investing time on your side to make the problem easy to reproduce for us. I understand that it's frustrating when things don't work the way you think they should work. However, remember that Eclipse is free software, and please consider if you are not already getting a lot more than your money's worth.
So, in your own best interest, could you please use Bugzilla (that way, everybody interested in the issue can follow the discussion), and help us reproduce the problem with as little time investment as possible on our side? I have already asked twice, on the bug, but I will ask one more time: Please attach [a file that will allow us to reproduce the issue] to the bug. I would expect to be able to use [list of steps] to get the source code into my Eclipse. Before uploading the attachment, it wouldn't hurt if you tried the import operation on a fresh workspace to confirm that we will be able to just run it. By the way, the recommended way to produce the file to attach would be [list of steps].
Thanks,
Boris
Hi [X],
Thank you for reporting a problem with Eclipse. But - and maybe it's just me - the private email you sent today comes across as demanding. You are asking us to help you quickly, without investing time on your side to make the problem easy to reproduce for us. I understand that it's frustrating when things don't work the way you think they should work. However, remember that Eclipse is free software, and please consider if you are not already getting a lot more than your money's worth.
So, in your own best interest, could you please use Bugzilla (that way, everybody interested in the issue can follow the discussion), and help us reproduce the problem with as little time investment as possible on our side? I have already asked twice, on the bug, but I will ask one more time: Please attach [a file that will allow us to reproduce the issue] to the bug. I would expect to be able to use [list of steps] to get the source code into my Eclipse. Before uploading the attachment, it wouldn't hurt if you tried the import operation on a fresh workspace to confirm that we will be able to just run it. By the way, the recommended way to produce the file to attach would be [list of steps].
Thanks,
Boris
Monday, January 18, 2010
Eclipse Labs
Mike wrote on his blog back in December that the Eclipse Foundation is "looking at creating an Eclipse Foundation affiliated forge where projects which are based on the Eclipse platform, but are not interested in hosting at eclipse.org can run their projects."
Click on the image, but it's not an official eclipse.org Eclipse Lab!
Admittedly, this announcement was a little vague, most probably because this is part of the Eclipse Foundation's program plan for 2010, and lots of details still need to be worked out. In the comment section, Mike wrote that he is "expecting to announce this at EclipseCon in March." This tells me that there are at least a few open questions that need to be answered, or negotiations that need to take place, or else this could have been announced in detail already.
As a committer representative on the Eclipse Board of Directors, I know a little bit more (but not too much) about this, but Board meetings are confidential, for good reasons - otherwise Mike wouldn't be able to openly discuss his vision and plans with the Board, which is one of the main functions of the Board of Directors.
So let me just go through what everyone does know (or can know) so far, based on what Mike has written in his blog posting and in the corresponding comment section, with a little bit of added interpretation and speculation just because it's rumour season:
Yet another non-eclipse.org Lab, click on the image!
Eventually, it will become important to handle the transition between Eclipse Labs and eclipse.org. For example, a project at Eclipse Labs may want to move to eclipse.org at a later point in time when it is more mature. Anything that can be done to ease this transition will be to the benefit of Eclipse, and it may make sense that projects make the transition in several steps. For example, an Eclipse project may want to depend on software from an Eclipse Labs project, at which point an IP review will have to be conducted on the eclipse.org side. Or a project at Eclipse Labs may want to become an incubating eclipse.org project, which would mean adopting the Eclipse processes but not necessarily a full IP review until the project makes a release at eclipse.org.
I hope this was useful information^H^H^H^H^H^H^H speculation. ;-)
P.S. I have used some words of Miles Parker's excellent blog post for the reasons why you would choose Eclipse Labs vs. eclipse.org as the place to run an open source project.
Click on the image, but it's not an official eclipse.org Eclipse Lab!
Admittedly, this announcement was a little vague, most probably because this is part of the Eclipse Foundation's program plan for 2010, and lots of details still need to be worked out. In the comment section, Mike wrote that he is "expecting to announce this at EclipseCon in March." This tells me that there are at least a few open questions that need to be answered, or negotiations that need to take place, or else this could have been announced in detail already.
As a committer representative on the Eclipse Board of Directors, I know a little bit more (but not too much) about this, but Board meetings are confidential, for good reasons - otherwise Mike wouldn't be able to openly discuss his vision and plans with the Board, which is one of the main functions of the Board of Directors.
So let me just go through what everyone does know (or can know) so far, based on what Mike has written in his blog posting and in the corresponding comment section, with a little bit of added interpretation and speculation just because it's rumour season:
- "An Eclipse Foundation affiliated forge where projects ... can [be] run" sounds to me like a concrete place for project hosting, i.e. a URL like eclipselabs.org. It turns out that this domain has been registered in December by the Eclipse Foundation. My hope is that soon, eclipselabs.org can be listed in the "Specific requirements" section of this wikipedia article on software hosting facilities, as a specialized software forge for Eclipse-related open source projects.
- This is for projects that "are not interested in hosting at eclipse.org", and "Eclipse Labs will hopefully over time form a powerful complement to the projects hosted at Eclipse.": Sounds to me like existing projects at eclipse.org will not be affected. Instead, I hope, this will be attractive by pulling together open source projects that currently would have to be started or hosted elsewhere (e.g. at Sourceforge, Github, Google Code, ...).
- "There will obviously be some constraints (e.g. only Eclipse Foundation projects can use the org.eclipse namespace, and be part of the release train)": Sounds like there will be a clear distinction between Eclipse projects on one side and Eclipse Labs projects on the other side. There are many good reasons why you may want to run a project at a less restrictive software forge, for example:
- minimal overhead to get started
- use whatever process you like for releases, adding and removing committers, adding dependencies to other software, etc
- no mandatory IP review
- benefit from the Eclipse brand and Eclipse marketing efforts
- use the same meritocratic principles and practices as every other project, making it easy to build trust across projects
- approved IP cleanliness, to ease adoption by large organizations and governments
Yet another non-eclipse.org Lab, click on the image!
Eventually, it will become important to handle the transition between Eclipse Labs and eclipse.org. For example, a project at Eclipse Labs may want to move to eclipse.org at a later point in time when it is more mature. Anything that can be done to ease this transition will be to the benefit of Eclipse, and it may make sense that projects make the transition in several steps. For example, an Eclipse project may want to depend on software from an Eclipse Labs project, at which point an IP review will have to be conducted on the eclipse.org side. Or a project at Eclipse Labs may want to become an incubating eclipse.org project, which would mean adopting the Eclipse processes but not necessarily a full IP review until the project makes a release at eclipse.org.
I hope this was useful information^H^H^H^H^H^H^H speculation. ;-)
P.S. I have used some words of Miles Parker's excellent blog post for the reasons why you would choose Eclipse Labs vs. eclipse.org as the place to run an open source project.
Subscribe to:
Posts (Atom)
Posts
