On 6/2/2015 2:16 AM, Simon Kitching wrote:
Hi Scott,
Maybe I shouldn't hijack a thread on the Felix list to ask about ECF,
but we are already talking about remote-services implementations, and
you are here so I'll do it :-)
Link [1] has instructions on using ECF's remote services on Karaf
which lead to this karaf features file:
http://download.eclipse.org/rt/ecf/3.8.0/site.p2/karaf-features.xml.
That file appears to indicate that 49 bundles are needed (the majority
from eclipse.org). Plus bundles to support whatever discovery provider
is desired. That doesn't seem reasonable; other remote-services
implementations have 1-3 bundles. Have I understood correctly?
For the latest the correct URL is:
http://download.eclipse.org/rt/ecf/latest/site.p2/karaf-features.xml
ECF's implementation is quite modular, and so is made up of more
bundles, generally much smaller and finer-grained.
<stuff deleted>
Looking at the commit-log for the osgi code, I see that you are the
only committer since at least the start of 2014. Is this correct?
I have done the majority of the commits from the start of 2014, but am
not the only committer. The source code history is not a very good
indicator of overall contributions for a project in this point in it's
life-cycle. Also, much of the recent coding work on ECF (by myself and
others) has taken place on our github repos[4].
<stuff deleted>
Regarding building from source : I see no Maven, Ant, Groovy or bnd
buildfiles in the sourcecode - just eclipse project files. Could you
point me to instructions on how to build artifacts from the
source-code (ideally outside of the Eclipse IDE)?
We currently use Eclipse + buckminster to build, and are part of the
Eclipse Simultaneous Release (which also uses buckminster). There are
contributors from Red Hat that are working adding to use Tycho to
build. FWIW, we also produce a maven repos as part of our build [A].
And is there any easy way of seeing what the dependencies of the
projects under osgi/bundles are (the kind of info visible in a maven
pom-file)?
From Eclipse, certainly. When Red Hat's contribution is in place you
will be able to do with maven-pom file as well.
Is there a list of the implemented "distribution providers" (network
protocols for the actual remote method invocation) available, with
details on the features and performance of each choice?
No, regrettably we don't have that. I've opened an enhancement request
to that effect [B]. There was some performance analysis work
contributed some time ago, but unfortunately I think it's likely pretty
obsolete by now.
I couldn't find one. In particular, I needed a high-performance
protocol - one that (a) keeps network sockets open rather than opening
a new connection for each call, and (b) uses a high-performance
serialization mechanism, ie not xml. I couldn't find any page with
that kind of information in it. The closest I found was:
*
https://wiki.eclipse.org/Discovery_and_Distribution_Provider_Configuration_Options
*
https://wiki.eclipse.org/Comparison_of_Discovery_and_Distribution_Providers
but neither of those pages are very useful. In particular, "r-osgi"
and "ecf generic" are not described in any way.
For the details about everything there's always 'use the source'. :-)
I can tell you that r-osgi, ecf generic, JMS, MQTT distribution
providers all
1) keep network sockets open as you describe;
2) use java object serialization as the default
I can also tell you that all of those providers, and the distribution
API that they implement (known to us as the 'remote services api'), are
customizable/extensible for both 1 and 2...meaning that if you wish, you
can replace both the serialization as well as the socket-level transport
with something more suitable for your use case without having to
implement a distribution provider from scratch. As a an example, that
is how websockets support was added in the 3.10 release cycle.
I propose moving this to ecf-dev or direct correspondence if you want
more details.
Scott
[A] http://build.ecf-project.org/maven/
[B] https://bugs.eclipse.org/bugs/show_bug.cgi?id=469155
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
