Sun Microsystems Systems Architecture Committee
Subject Eclipse For Java Developers
Submitted by Alexandre Iline
File LSARC/2008/626/opinion.html
Date Nov 18, 2008
Committee # This file is automatically generated on a daily basis by create_membershiplists. Mark Carlson, Lloyd Chambers, Thomas Childers, Aniruddh Dikhit, Danek Duvall, John Fischer, Ed Hunter, Chris Kasso, Arieh Markel, Margot Miller, Stephen Uhler, Jyri Virkki. Mark Carlson, Lloyd Chambers, Aniruddh Dikhit, John Fischer, Margot Miller. Minority: (Michael Kearney). Abstain: Tom Childers, Ed Hunter, Jyri Virkki.
Product Approval Committee LSARC

1. Summary

2. Decision & Precedence Information

3. Interfaces

4. Opinion

5. Minority Opinion(s)

5.1 SWT Library

My opinion is that it's not a maintenance nightmare to support two versions or locations for the SWT components and I can easily envision the need to have a production version and a development version of a library. How else to produce software for the next supported release?

Secondly, this arrangement makes the Eclipse install on Solaris different from all other OSes. This will serve to reduce acceptance by the development community.

Thirdly, every step Sun takes that diverges our version of Eclipse from the freely downloadable version is wasted effort on our part. It increases the time between new releases and their availability on Solaris as well as putting a burden on the NetBeans team.

I think the fundamental issue is the difference between a developer platform and a production platform. Solaris as a developer platform MUST allow open source tools like this to function as designed, otherwise we sacrifice developer mindshare. The TCRs established by this review actually cripple the deliverable. Furthermore, a developer (non-root) installation has no system-wide reliability or security impact.

SWT actually belongs to Eclipse, and Eclipse has taken ownership of it and will automatically update it through their own mechanism.

5.2 IPS

To my mind, ideally, an open project such as OpenSolaris should not always be held captive to support requirements by SMI. With regard to particular other open source projects, especially where those projects maintain their own community-driven support channels; we should not always, as a rule, opt to override those support ecosystems on the assumption that this provides lower support costs for SMI. In this particular case, this very likely would result in a broken user experience, and is a great departure from the integration of this tool on every other platform that it runs on. I would add that the TCR requiring that the auto-update functionality be decorated with obvious warnings increases the user experience gap. This most likely leaves the user in a lurch the moment he attempts to install one of the copious plug-ins or add-ons and the update functionality is invoked automatically.

I believe the onus here should be on the IPS project team to address the need to integrate future products which feature self-updating functionality. Until SMI develops an answer for how it will thrive as downstream consumer of so many projects originating in other open communities, especially those that provide their own patch/fix/update/extend ecosystems, it can not do no better than always discourage or disable this functionality in projects. A solution should be found for better integration of this functionality within the packaging system so that the answer will not always be "it self-updates everywhere but here".

6. Advisory Information

Appendices