[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [soa-iwg] ECF remote services
|
Ian Skerrett wrote:
Scott,
Obviously you aren't willing to have a professional, courteous
exchange on this subject, so I will leave it at that.
1) I don't think it's discourteous to call something for what it
is...and it's sadly not surprising to me that you would dismiss any such
criticism. Sadly, I've noticed that's the typical pattern in
policy-level criticisms: dismiss and then denegrate.
2) As for professional, I think the behavior of this working group (and
the associated policies of the Foundation, frankly), is the lowest
extant example of unprofessional (not to mention closed) behavior.
For the reference of others reading this mailing list, here is the
process to create a package
http://wiki.eclipse.org/EPP/How_to_create_a_package. It is a bit out
of date, with references to Ganymede but the general principles are
still valid. Feel free to contact me if you have questions or need help.
For others reading this mailing list, please don't believe the *untrue*
assertion that the EPP package process is open...it's clearly not. To
prove this to yourself, all you have to do is ask the following
questions: how many EPP packages have been added over the past X years
since inception? Of these, who decided upon their addition? How many
projects have gone through the process described by the URL? (I'll give
you a hint: 0). Also, as an example of how new EPP package proposals
from projects are actually treated see [1].
Finally, I want to return to the original question, and not have this
whole absurdity get sidetracked further (and, of course, dismissed, and
denegrated).
Here's a summary:
1) ECF has produced a working, full implementation of the OSGi 4.2
remote services specification...the *only* actual OSGi standard
*directly* relevant to SOA.
2) We offer this as a contribution to the SOA runtime package. As
Eclipse/Equinox/EclipseRT are based upon OSGi standards, I don't think
it's controversial that such an implementation would be of value to the
SOA community. Particularly since we offer a number of unique features
as detailed in this blog posting:
http://eclipseecf.blogspot.com/2010/01/osgi-remote-services-from-ecf.html
3) Like other runtime projects, we have/are required to focus on the
runtime implementation of the relevant OSGi SOA standards, while working
cooperatively with tooling projects to assure that tooling exists (e.g.
PDE, DS, others) for the runtime work. This is what we have done, and
will continue to do. Further we also have some remote-specific tooling
that we have/will continue to deliver ourselves.
4) This working group is apparently rejecting this contribution to the
SOA runtime package, based upon a 'requirement' that we deliver *both*
runtime and tooling functionality. As I've stated before, this
requirement is bogus, because if applied by policy (instead of just ad
hoc to this one contribution) it forces any runtime project to do
out-of-scope work (and/or any tools project to also do out-of-scope
work)...effectively limiting the contributions to those projects that do
both.
I consider such a decision clearly and obviously not in the interests of
SOA developers or the SOA, OSGi, and/or EclipseRT communities. Would
anyone care to present a cogent argument otherwise? (without appealing
to the IWG charter, EF policy, the Board, SOpera, etc., etc., etc)
Scott
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=218829
