Jeff McAffer wrote:
This is great news either way.
I agree. I just want to say publicly how thrilled I am that both
Markus and Jan have agreed to participate in ECF. Having access and
coordination with the expertise and codebases for jSLP (discovery) and
r-OSGi (remoteservices) is very exciting.
the function available is the most interesting part. Having it at
Eclipse is certainly more convenient but then I'm sure the Apache folks
would say the same about having it at Apache. Running the legal system
here at Eclipse may take some time but at least for incubation it is
a big deal. Some additional topics/thoughts
- What is the timeline for the SLP
That is, will there be something in place/released by Ganymede?
There are two components to this answer:
jSLP is at RC1: http://jslp.sourceforge.net/ and Jan and Markus have
conveyed to us that there is small amount of work to do to get it to
final. We obviously need to get it to final before we 1) submit a CQ
to IPZilla and 2) put into Orbit. I'll let Jan give details about his
and Markus' schedule on this, but I got the impression it could be at
final by ~end of Nov without any trouble.
The ECF discovery provider based upon jSLP (by Markus Kuppe) is already
done. There will likely be only trivial changes to it in response to
jSLP getting to final. We've currently got it at the ecf1.osuosl.org
CVS server, where we have other stuff in incubation. When Markus is
approved as committer for ECF (should happen this week), then we'll
submit a CQ for it as an EPL contribution get it through the process
I'm hopeful/expecting that both of these will be all the way through
the IP approval process and a part of the ECF distribution well before
EclipseCon 2008. For me, it's a given for ECF 2.0/Ganymede.
- For these things we need to look
how to consume intermediate results. I'm not sure how this would work
the IP process. We could likely get "milestones" from Apache
and run them through IP for initial license review. Code from Apache
generally goes through pretty fast.
- ECF having graduated is no longer
entitled to parallel IP consideration. Given the nature of ECF
new protocols etc) this is something we should look at addressing.
Yes. We have been maintaining an 'ECF Extras' site at the OSU Open
Source Lab for bundles which cannot be under EPL (e.g. yahoo provider,
which is based upon GPL code), and for bundles that are 'not ready for
submission to EF CQ process' (like the ECF SCP provider by
Markus...since it's dependent upon jSLP). We have a separate build for
these bundles, and a separate CVS server and web server...i.e.
http://ecf1.osuosl.org (anonymous CVS given on the web page).
I suppose we could also/instead take the tack that other projects are
taking on this, and have an 'ECF Incubator' project. But I've sort of
been waiting to see how the organizational/process discussions go on
this, because obviously the 'parallel incubators' approach creates its
own set of problems as we begin to approach all projects having a
parallel incubator project...
Yes, let me clearify this a bit. My intention is
was to donate my project to where they are most helpful (with respect
other projects going on in the community and how the flavor of the
fits into the big picture). That's why I split things like that.
R-OSGi perfectly fits into the environment of ECF and the efforts of
Eclipse community around distributed OSGi services seemed most mature
On the other hand, jSLP is a protocol implementation and Apache has a
tradition in this field. Putting jSLP into the context of Apache
Server helps the project in several way, one is that there will
be a full Java SLP DA implementation, another is that there might be
interest in extending the implementation with things like IPv6 support
and other issues that remained open so far.
All in all, I have always been at the point that the large open-source
projects have enough in common so that they should be able to
despite obvious differences in their culture and structure. I hope you
understand my point.
ecf-dev mailing list
ecf-dev mailing list