At work we have had an agreed upon coding style for a couple of years, but it hasn't been enforced so not everybody have followed it. When the style was established, everyone was using IntelliJ IDEA so the style was based on IDEA settings. Now it's a split between IDEA and Eclipse, so recently I was trying to create matching style settings in IDEA, Eclipse and CheckStyle -- the first two for automatic formatting and the latter for checking.
Both IDEA and Eclipse have some problems. For example Eclipse puts more whitespace in JavaDocs and I could not configure the JavaDoc formattings to be compatible so I just turned it off in IDEA. Eclipse tends to not respect the maximum line width setting for code very well -- occasionally a few characters will go beyond the limit. IDEA has the same problem for JavaDocs. Eclipse also has some problems with optimizing imports (note to self: should report /comment on bugs about those, maybe even contribute patches) that make it incompatible with IDEA.
But the biggest problem is that Eclipse doesn't have a very good user story for configuring all of this. The code formatter options (Java -> Code Style -> Formatter) are the oldest and they are pretty good -- easy to manage profiles and everything can be exported/imported. The same can be said about code clean up (Java -> Code Style -> Clean Up), but I would argue that these two separate concepts should be merged.
There is also a problem of redundancy: Java -> Editor -> Save Actions use the existing Formatter and Organize Imports settings, but they do not use the Code Clean Up settings, instead here you have to configure those again, in a non-shareable way.
However, Code Templates, Organize Imports and the general settings are worse -- they don't support different profiles, and Organize Imports does not export/import all settings (such as the number of static imports needed for .*). All of this makes it quite hard to share these settings between a team.
I think a good solution would be to replace the profiles and import/export in the different pages (formatter, clean up) with more general Code Style profiles and import/export that would cover every setting under Java -> Code Style. Then again, maybe more granular profiles are better for some reason that I fail to see, but I'm sure they could be retained somehow while solving the problem I just described.
And another idea: as Eclipse is becoming an IDE for more and more languages, and many of these language tools could possibly offer code formatters, compiler options etc., why not think of a generic code style settings UI that would be extensible by plug-ins for specific languages.
Saturday, July 21, 2007
Friday, July 06, 2007
Rhythm in open source
Mark Shuttleworth (what an awesome last name, BTW) thinks that KDE, Gnome and OpenOffice.org would benefit from a common release schedule, preferably six months like Ubuntu. I'm wondering if Eclipse's annual release trains also influenced his opinion and whether these kind of coordinated/rhythmic releases have been done elsewhere in the open source world or are Eclipse and Ubuntu the only ones? I think it would be great for the open source community if the rhythm spread and releases became more predictable.
Wednesday, July 04, 2007
Eclipse 4.0 should be about usability and integration
Eclipse 4.0 Io is probably 2 years off now (or 3, if Io will in fact be 3.5?) , considering the very precise yearly release cycle that just brought us Europa and will bring Ganymede next year. And if there are going to be some more fundamental changes in 4.0 than the releases since 3.0 have had, I think it's time to start talking about this now. Really big changes can't happen during one release cycle.
So that it's understandable where I'm coming from: I've been following the Eclipse community for the past two and a half years, as an occasional hacker, but mostly a user and a somewhat objective observer. Or at least that's what I like to think -- I'm actually a pretty big fan of Eclipse so there definitely is some bias. I heard there was some discussion on Eclipse 4.0 already during EclipseCon 2007. Sadly, I couldn't attend EclipseCon myself. Note: I'm also linking to some old related discussions in this post -- I think some of them are still valid.
Even though Eclipse is growing very fast, I think there is still a lot of untapped potential in the projects hosted by The Eclipse Foundation. That potential lies in the integration of the various tools so that they can be composed into wholes that are greater than the sum of their parts -- creating synergy. To some extent this is already happening, but at the moment there are still a lot of areas where it feels like the tools should work better together, but they don't. There are endless possibilities for small improvements that span projects, but actually filling that potential may be somewhat hard to do.
The Callisto and Europa release trains have definitely been a big step in the right direction, but they have not set integration as a top priority and it would probably be too much to expect much greater strides towards this from Ganymede. But as a user, I'd like to see this become a priority for Eclipse 4.0 (or soon after). If Eclipse just keeps extending wider and wider into new, though definitely cool areas (which it must do, of course), while not paying much attention to keeping the expanding core cohesive, I fear it may eventually start losing focus.
In the past there has been some talk about "extensible frameworks and exemplary tools" and that the focus of Eclipse is sometimes a bit more on providing a platform rather than a great end-user tool. This focus may vary from project to project. But parts of Eclipse do make a great end-user tool (perhaps most notably JDT and PDE, but there are others too), and other parts less so. Of course this undoubtedly has to do with the maturity and age of the projects as it takes time to become an awesome tool.
But perhaps there should be more effort made in the area of usability and making a set of "core" projects better integrated and of a more uniform quality, whatever exactly the "core" would compose of -- probably platform + the more popular language tools + PDE + Mylyn + ECF + data + modeling + reporting + testing and some other projects as well. More focus should be put on the areas where these "core" projects touch. This would in turn probably put a lot of pressure on the platform itself, which may need to become even more flexible, even though it already is probably the most flexible and in my opinion the best application platform in the known universe.
Some examples of what I mean, but these may be somewhat superficial and don't really go deep into details:
* Mylyn bridges for more projects -- perhaps even all of the release train projects
* Taking advantage of potential communication/collaboration features offered by ECF and other projects (Corona comes to mind)
* More BIRT reports in other projects
* Make the static analysis from TPTP more prominent. IDEA has had this for years. How many users know that they can get static analysis and a profiler for Java by installing TPTP?
* Make Eclipse a competitive database design & administration tool
* Make Eclipse a competitive UML modeling tool
* ETC.
I hope not all of this will be left for vendors to do in their Eclipse based products -- that could make Eclipse itself lag behind.
Oh, and by the way, great work everyone who made Europa happen! You all deserve a vacation now, but don't go resting on your laurels! :)
So that it's understandable where I'm coming from: I've been following the Eclipse community for the past two and a half years, as an occasional hacker, but mostly a user and a somewhat objective observer. Or at least that's what I like to think -- I'm actually a pretty big fan of Eclipse so there definitely is some bias. I heard there was some discussion on Eclipse 4.0 already during EclipseCon 2007. Sadly, I couldn't attend EclipseCon myself. Note: I'm also linking to some old related discussions in this post -- I think some of them are still valid.
Even though Eclipse is growing very fast, I think there is still a lot of untapped potential in the projects hosted by The Eclipse Foundation. That potential lies in the integration of the various tools so that they can be composed into wholes that are greater than the sum of their parts -- creating synergy. To some extent this is already happening, but at the moment there are still a lot of areas where it feels like the tools should work better together, but they don't. There are endless possibilities for small improvements that span projects, but actually filling that potential may be somewhat hard to do.
The Callisto and Europa release trains have definitely been a big step in the right direction, but they have not set integration as a top priority and it would probably be too much to expect much greater strides towards this from Ganymede. But as a user, I'd like to see this become a priority for Eclipse 4.0 (or soon after). If Eclipse just keeps extending wider and wider into new, though definitely cool areas (which it must do, of course), while not paying much attention to keeping the expanding core cohesive, I fear it may eventually start losing focus.
In the past there has been some talk about "extensible frameworks and exemplary tools" and that the focus of Eclipse is sometimes a bit more on providing a platform rather than a great end-user tool. This focus may vary from project to project. But parts of Eclipse do make a great end-user tool (perhaps most notably JDT and PDE, but there are others too), and other parts less so. Of course this undoubtedly has to do with the maturity and age of the projects as it takes time to become an awesome tool.
But perhaps there should be more effort made in the area of usability and making a set of "core" projects better integrated and of a more uniform quality, whatever exactly the "core" would compose of -- probably platform + the more popular language tools + PDE + Mylyn + ECF + data + modeling + reporting + testing and some other projects as well. More focus should be put on the areas where these "core" projects touch. This would in turn probably put a lot of pressure on the platform itself, which may need to become even more flexible, even though it already is probably the most flexible and in my opinion the best application platform in the known universe.
Some examples of what I mean, but these may be somewhat superficial and don't really go deep into details:
* Mylyn bridges for more projects -- perhaps even all of the release train projects
* Taking advantage of potential communication/collaboration features offered by ECF and other projects (Corona comes to mind)
* More BIRT reports in other projects
* Make the static analysis from TPTP more prominent. IDEA has had this for years. How many users know that they can get static analysis and a profiler for Java by installing TPTP?
* Make Eclipse a competitive database design & administration tool
* Make Eclipse a competitive UML modeling tool
* ETC.
I hope not all of this will be left for vendors to do in their Eclipse based products -- that could make Eclipse itself lag behind.
Oh, and by the way, great work everyone who made Europa happen! You all deserve a vacation now, but don't go resting on your laurels! :)
Friday, June 22, 2007
Equinox & ECF serving interactive fiction
After a couple of years of being lazy and procrastinating, I finally got Ziggy to the point where we now have it running live [Beta] :) at Idle Thumbs (thanks Spaff, Jake and others from Idle Thumbs for your help with this) . Ziggy is a server side application based on Equinox and ECF, it enables people to play interactive fiction games on web forums, acting as a bridge between the forum and an IF virtual machine.
At first it was just plain Java, a very simple app hacked together in only a few days, but has suffered many a rewrite since then and is now fully OSGified. I separated it into four main components: server, Interactive Fiction API & implementation, Bulletin Board API & implementation, management client -- all of these are now packaged as OSGi bundles and the client is an RCP application. The Bulletin Board API is open source and is also incubating at ECF (still needs some work before becoming part of a release). The Interactive Fiction API may also become open source at some point, and there are other interesting uses for it. For example another plug-in I developed allows playing these games inside an Eclipse console, which I hope to make available soon.
Thanks to taking advantage of ECF's communications container abstractions, Ziggy's potential is not actually limited to bulletin boards -- it was easy to add just a bit of code to make it work over instant messaging and IRC, but this aspect of it is not public yet.
At first it was just plain Java, a very simple app hacked together in only a few days, but has suffered many a rewrite since then and is now fully OSGified. I separated it into four main components: server, Interactive Fiction API & implementation, Bulletin Board API & implementation, management client -- all of these are now packaged as OSGi bundles and the client is an RCP application. The Bulletin Board API is open source and is also incubating at ECF (still needs some work before becoming part of a release). The Interactive Fiction API may also become open source at some point, and there are other interesting uses for it. For example another plug-in I developed allows playing these games inside an Eclipse console, which I hope to make available soon.
Thanks to taking advantage of ECF's communications container abstractions, Ziggy's potential is not actually limited to bulletin boards -- it was easy to add just a bit of code to make it work over instant messaging and IRC, but this aspect of it is not public yet.
Monday, June 18, 2007
Padclipse Text Editor
Padclipse is a new very light weight distribution of Eclipse that only contains the Text Editor and a few other plugins. The first pre-alpha release based on Eclipse 3.3RC4 just came out, but is not well tested, so caveat emptor! You can download it for Windows, Mac or Linux.
The first release of the "Lite" edition contains RCP, Text Editor, Compare and Search and not much else from the Eclipse SDK. Also included for convenience are EclipseColorer editor with syntax highlighting for many programming languages and HTTP File System.
The download is only 20MB and I've seen start up times from 2 to 5 seconds.
Future editions might include "Team" (CVS, SVN, Mylyn, ...), "Full" (Team + WST XML) and perhaps "Micro" (taking out everything that can possibly be taken out while leaving the text editor).
Padclipse also brings some new functionality that makes Eclipse easier to use as a simple editor:
The first release of the "Lite" edition contains RCP, Text Editor, Compare and Search and not much else from the Eclipse SDK. Also included for convenience are EclipseColorer editor with syntax highlighting for many programming languages and HTTP File System.
The download is only 20MB and I've seen start up times from 2 to 5 seconds.
Future editions might include "Team" (CVS, SVN, Mylyn, ...), "Full" (Team + WST XML) and perhaps "Micro" (taking out everything that can possibly be taken out while leaving the text editor).
Padclipse also brings some new functionality that makes Eclipse easier to use as a simple editor:
- Files (URI-s) can be opened via command line parameters, and consequent launches will open editors in a single instance of Padclipse (per user).
- Files will be automatically linked to the workspace to make local history and other features be available to all files. This will be improved in future versions.
- Future versions will improve OS integration and general usability.
Tuesday, May 22, 2007
Open Software
The terms Free Software and Open Source Software are cumbersome to use, especially when speaking with laity.
Free Software seems to often need an extra qualifier "free as in freedom" (as opposed to "free as in beer"). Without that qualifier, it can have a negative connotation, as people confuse it with Freeware, which is (was?) often thought of as something gratis, but of lesser function or quality than commercial offerings.
Open Source Software has the word "source" in the middle that needs extra explanation for many people. It would be much simpler to explain Open Software, without all the source (or sores, as Hani Suleiman would say). With the emergence of Open Source Hardware, where source can have a somewhat different meaning, I think Open Hardware would also be a better fit.
Simply open is good. And it can more easily include other qualities we've come to associate with, but what the words "open source" don't actually cover: open development, open processes, open attitude. It can include both Free Software and Open Source Software, and hopefully better associations with "open software" would form in people's heads, like: it's transparent, you can take it apart, modify it, distribute it and be part of it.
So, if you agree with me, lets start using the term open software from now on. :)
PS. Lets not even speak of alternatives like Free/Libre/Open-Source Software (but don't forget to FLOSS!)
Free Software seems to often need an extra qualifier "free as in freedom" (as opposed to "free as in beer"). Without that qualifier, it can have a negative connotation, as people confuse it with Freeware, which is (was?) often thought of as something gratis, but of lesser function or quality than commercial offerings.
Open Source Software has the word "source" in the middle that needs extra explanation for many people. It would be much simpler to explain Open Software, without all the source (or sores, as Hani Suleiman would say). With the emergence of Open Source Hardware, where source can have a somewhat different meaning, I think Open Hardware would also be a better fit.
Simply open is good. And it can more easily include other qualities we've come to associate with, but what the words "open source" don't actually cover: open development, open processes, open attitude. It can include both Free Software and Open Source Software, and hopefully better associations with "open software" would form in people's heads, like: it's transparent, you can take it apart, modify it, distribute it and be part of it.
So, if you agree with me, lets start using the term open software from now on. :)
PS. Lets not even speak of alternatives like Free/Libre/Open-Source Software (but don't forget to FLOSS!)
Subscribe to:
Posts (Atom)