My worry about this thread is that there are two very distinct
issues that are getting conflated, and as long as that happens, I doubt there
will be any progress and just heated disagreement.
1 – The process of working groups, packages, charters and
distribution. I don’t think this group or this thread is the right
place for the conversation. It needs to take place with the board
Committer reps, at the Architecture council, at the EMO, etc. As I’ve
noted before, I don’t know if we’ll ever agree about how these work
– but the processes and programs have been agreed to and built in past
years after much consideration and debate. If there are things that need
to be addressed as you are saying – then the discussion needs to happen
elsewhere.
2 – You are asking what looks like a very reasonable
question to include some well regarded software in the SOA IWG Package. I
still don’t think anyone has said no to that – just that the IWG
requires help with it’s integration and inclusion and it sure would be
nice if there was some way that it fit with the other components. The
reason is, because as you’ve noted there has been a lot of disjoint SOA
projects at Eclipse, and a very important goal of the IWG is to try to decrease
that. Just like the release trains have taken many years to increase the
cohesiveness of the core, the SOA IWG is looking to do the same.
-
Don
From: soa-iwg-bounces@xxxxxxxxxxx
[mailto:soa-iwg-bounces@xxxxxxxxxxx] On Behalf Of Scott Lewis
Sent: January 12, 2010 6:35 PM
To: SOA Industry Working Group
Subject: Re: [soa-iwg] ECF remote services
The SOA charter was poorly constructed. It doesn't
reflect the (obvious) truth that requiring a runtime project to do all it's own
tooling (especially when existing tooling works perfectly fine...as in our
case...let's not forget that), and requiring a tooling project to do it's own
runtime just *doesn't make any sense*...except if the charter is written precisely
to enable a single project or company to use the working group to it's benefit.
In other words, I would call this aspect of the SOA charter a load of
crap. *WHY* is the integration of tooling and runtime a fundamental
guideline for the working group? Why does this make sense when there are
at least 5 runtime projects that are doing aspects of SOA, and at least 10
tooling projects that are also doing aspects of SOA? To exclude any/all
of these efforts because the SOA charter was poorly conceived doesn't make any
sense.
So, for example of the absurdity of this: would you also say that Equinox
can't contribute runtime components to the SOA package because the Equinox team
isn't doing tooling? That EMF can't/couldn't contribute SOA tooling
because they are not implementing the OSGi remote services specification
(runtime)? Then why is ECF's implementation of the OSGi remote services
runtime standard excluded because of this? (especially since as I've
already pointed out we *do indeed* have tooling available at this very
moment...e.g. PDE, DS, and our own).
Scott
Ricco Deutscher wrote:
Hi Scott,
>I would consider that a distinction without a relevant difference
I disagree. The integration of tooling and runtime was a fundamental guideline
from the very beginning of this group. The Eclipse SOA charter (http://www.eclipse.org/org/industry-workgroups/soawg.php)
says explicitly:
In order to provide incentives to A) form a coherent and integrated SOA
platform, and B) to promote adoption, there will be a set of criteria ... This
set of criteria will cover as well for the tooling and as well for the runtime.
The fulfilment of either tooling only or runtime only will be not sufficient
....
Best,
Ricco
Am 12.01.10 23:17 schrieb "Scott Lewis" unter <slewis@xxxxxxxxxxxxx>:
Donald,
Donald Smith wrote:
> Hi Scott,
>
> The difference being that Virgo is a project, but the inclusions being
> discussed here are for the IWG Package.
>
> That is not a statement of disagreement to your recommendations for
> inclusions -- just pointing out the difference so we can focus the
> discussion.
>
I would consider that a distinction without a relevant difference (IWG
packages and projects).
Why? Because
1) projects are the entities that actually produce sw for inclusion in
packages...i.e. IWG doesn't produce any sw for distribution via
packages...they only decide what's included in packages from relevant
projects (in this case...in other cases EPP package contents are decided
in other, arguably even more mysterious ways).
2) projects have to focus in certain areas (runtime, tooling,
etc)...i.e. some things should/must be out of scope (that's only reasonable)
3) cooperation with/dependence on other projects (rather than vertical
project silos) is a good, even necessary thing...for the community and
for the projects
So sure, there's a definitional difference between 'IWG packages' and
'projects'...but WRT these points about sw creation and distribution by
*projects*, it's not a meaningful difference.
Scott
_______________________________________________
soa-iwg mailing list
soa-iwg@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/soa-iwg
_______________________________________________
soa-iwg mailing list
soa-iwg@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/soa-iwg
