<html>
<head>
<title> Opinion: Eclipse For Java Developers </title>
<body>
<table border>
<th colspan=2> Sun Microsystems Systems Architecture Committee <BR>
Sun Proprietary/Need to Know </th>
<tr><th>Subject </th> <td> Eclipse For Java Developers
</td></tr><tr><th>Submitted by </th> <td> Alexandre Iline
</td></tr><tr><th>File </th> <td> LSARC/2008/626/opinion.html
</td></tr><tr><th>Date </th> <td>Nov 18, 2008</td></tr><tr><th>
<A HREF="mailto:LSARC at sun.com?subject=case 2008/626 opinion">Committee</A>
</th><td>
# 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.
<!--
List the majority first, in alphabetical order. Except, place the name
of the person writing the majority opinion first. List the minority
second, after a "." and the word "Minority:". Again, place the name
of the author of the minority opinion first, but then alphabetically.
E.g.: Joe Blow, Allan Able, Charlie Carlson. Minority: George Wrong,
Devils Advocate. List abstentions last.
Interns should not be included in the committee list unless an intern
wrote the opinion. In that situation, list the intern in parentheses
after the case owner. E.g.:
August Case-Owner (Aspiring Intern)
Note that [ARC_DIR]/committee contains a list of committee
members in a form suitable for inclusion here. The review minutes
are another source for this information.
-->
</td></tr><tr><th>
<A HREF="mailto:${PACemail}?subject=case 2008/626 opinion">Product Approval
Committee</A></th>
<td>
LSARC
</td></tr>
</table>
<h1>1. Summary </h1>
<ul>
<p>Eclipse is an integrated development environment (IDE).</p>
<p>Eclipse for Java Developer is one of the most popular open source Java IDEs,
providing
functionality in order to simplify development of extensible, modular
and cooperating Java
based desktop applications.</p>
<p>URL: http://www.eclipse.org.</p>
<!--
In this section, put a few sentence synopsis of the proposal.
Make the description ample enough for a wide audience, as this
is all that the majority of your future readers will use to
identify and understand this project.
-->
</ul>
<h1>2. Decision & Precedence Information</h1>
<ul>
<!--
This section follows a specific phrasing and order. One sentence
paragraphs are best here.
* Whether or not the proposal is accepted.
* If there are mandatory modifications that the acceptance is
conditional upon, state that they are specified in Appendix A
(the TCRs). If the proposal is accepted unconditionally,
simply state that it's accepted.
-->
[The project is approved as specified in reference [1]]
[, but as modified by the required technical changes
listed in Appendix A].
<!--
* The classification of the deliverable as a
major [incompatible],
minor [compatible enhancement], or
micro [a "replicant" like a port or driver; or a bug fix]
and for what product line [Solaris, Web Download, a specific
unbundled product, ...].
See the Release Taxonomy document for details...
/BestPractices/ToDo/release.taxonomy/Taxonomy.ps
-->
[The project may be delivered in a minor release of Solaris.]
<!--
* The table of projects that must be delivered no later than this
project. (If none, omit this paragraph and the following table.)
List this in the format shown, with project IDs or case numbers to the
left and the text of the description (usually the case's title) to the
right, as a relative link if possible.
-->
[The project depends on the following other projects and may not
be delivered before them.
<table border>
<tr><th> Case </th><th> Name </th></tr>
<tr><td> [PSARC/1994/038]
</td><td><a href="[../../../PSARC/1994/038/opinion.html]">[Making FNS
XFN Compliant]</a>
</td></tr>
<tr><td>[950331_scott.mcnealy]
</td><td>[Making MS SUN Compliant]
</td></tr>
</table>
<br>
]
<P>
</ul>
<h1>3. Interfaces</h1>
<ul>
<!--
This section should identify the project's interfaces and their
classifications in the interface taxonomy. A tabular format is
most appropriate for this information, listing imported interfaces
in a separate table from interfaces being exported.
Two skeleton tables appear below.
Fill them in with export and import information.
Try to make comments succinct.
Useful information to include in the Comments field includes:
- What kind of interface it is (function, library, file, ...)
- A cross reference to a reference material entry describing it
-->
<p>
<!-- EXPORTED INTERFACES -->
<table border>
<tr><th colspan=3>Interfaces Exported</tr>
<tr><th> Interface Name </th><th> Classification </th><th> Comment
</th></tr>
<tr><td> eclipse
</td><td> Uncommitted
</td><td> Package
</td></tr>
<tr><td> /usr/eclipse
</td><td> Uncommitted
</td><td> Installation directory
</td></tr>
<tr><td> eclipse
</td><td> Uncommitted
</td><td> Commandline syntax
</td></tr>
<tr><td> SWT
</td><td> Uncommitted
</td><td> Library
</td></tr>
<tr><td> JUnit
</td><td> Uncommitted
</td><td> Java Library
</td></tr>
<tr><td> Eclipse Platform
</td><td> Uncommitted
</td><td> Set of Java Libraries
</td></tr>
</table>
<p>
<!-- IMPORTED INTERFACES -->
<table border>
<tr><th colspan=3>Interfaces Imported</tr>
<tr><th> Interface Name </th><th> Classification </th><th> Comment
</th></tr>
<tr><td> j6dev
</td><td> Committed
</td><td> Package
</td></tr>
<tr><td> GTK
</td><td> ???
</td><td> Library
</td></tr>
</table>
</ul>
<h1>4. Opinion</h1>
<ul>
[Place the text of any opinion here.]
<!--
Place the text of any opinion here. Note that if the decision is
to reject then opinion text is mandatory. The decision should,
where possible and especially for a rejection, express the principles
that underly the decision. If the application of the principle is
limited or "special" for this case, be sure to identify that.
This section should also capture the content and resolution of the major
issues uncovered during the committee's deliberations. Unless there
are only one or two issues, use a subsection for each, by adding
headers for each issue or related group of issues; e.g.:
-->
<h2>4.1 Issue Title</h2>
<ul>
[Text about that issue here.]
</ul>
</ul>
<h1>5. Minority Opinion(s)</h1>
<h1>5.1 SWT Library</h1>
<p>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?
<p>Secondly, this arrangement makes the Eclipse install on Solaris
different from all other OSes. This will serve to reduce acceptance by the
development
community.
<p>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.
<p>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.
<p>SWT actually belongs to Eclipse, and Eclipse has taken ownership of it and
will
automatically update it through their own mechanism.
<h1>5.1 IPS </h1>
<p>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.
<p>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".
<h1>6. Advisory Information</h1>
<ul>
[Any editorial or advisory information goes here.]
<!--
If there is editorial, or advisory information the committee wishes
to express, place that here. This is information that may be used
by the project or management as they see fit. It could include
observations about costs, techniques, suggestions for different
design decisions, and the like. This section is where advice to
product approval committees about the project's ramifications should go.
-->
</ul>
<h1>Appendices</h1>
<ul>
<h2>Appendix A: Technical Changes Required</h2>
<!--If there are mandatory technical changes, enumerate them here.-->
<ol>
<li>Eclipse creates the password file with 644 permissions and
the
directories with 755 permissions. This is too permissive. It
must create the file with 600 or 400 and the directories with 700.
</li>
<li>Eclipse uses a single key to generate the encrypted
password file
for CVS for every installation. It must use a different key for
each install.
</li>
<li>Eclipse uses the SWT libraries, which are included in
Solaris as
part of LSARC 2008-462. Eclipse must use the common system-wide
SWT and not its own.
</li>
<li>Eclipse must include a man page with the admonishment that
using the
standard Eclipse installation and update mechanism will make updates
using IPS difficult or impossible.
</li>
</ol>
<!-- else, if none: -->
<h2>Appendix B: Technical Changes Advised</h2>
<!--As in Appendix A, list specific changes that the committee
advises.-->
<!-- else, if none: -->
<ul> None </ul>
<h2>Appendix C: Reference Material</h2>
<!--List reference material.
The references must include the project's specification and
should
include the case's mail file, and other submission material as
appropriate. It is often useful to include references to
related
cases, as well. This section should help guide the reader
through
the material, so include a short explanation with each
reference.
URLs should be relative to the current directory, assuming
that this file is in the case directory, e.g. if this file
is assumed to be in directory *ARC/1996/666 .
HTML files should have the extension ".html".
Text files should have the extension ".txt".
PostScript files should have the extension ".ps".
Other kinds of files should include the file format
in the descriptions. Also, large files (approx.
larger than 1M) should so state in the description.
-->
Unless otherwise stated, path names are relative to the
<A HREF="/Projects/LSARC/2008/626">
case directory (LSARC/2008/626)</A>.
<P>
<ol>
<!-- 1 --><li> <a
href="[commitment.materials/20081104.2008.626.commitment]">
[commitment.materials/20081104.2008.626.commitment]
</a><br>
[meeting minutes]
<!-- 2 --><li> <a
href="[commitment.materials/20081118.2008.626.commitment]">
[commitment.materials/20081118.2008.626.commitment]
</a><br>
[meeting minutes]
<!-- and so on -->
</ol>
</ul>
</body>
</html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20081120/2e960519/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Michael_Kearney.vcf
Type: text/x-vcard
Size: 347 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20081120/2e960519/attachment.vcf>
