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
|
