[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] New tutorial: Creating your first OSGi Remote Service
|
Hey Markus,
On 12/7/2013 12:06 AM, Markus Alexander Kuppe wrote:
<stuff deleted>
content-wise: - the less configuration, the better. Thus, lets remove
the ECF specific properties from the service registration or move it
into an advanced section.
Ok, I've removed it. I would like to have other, more advanced
tutorials, so we can describe discovery and distribution provider
configuration in those. Perhaps there should be another tutorial just
for configuration...even separate ones for discovery and distribution
perhaps.
- Using LAN based discovery has its pitfalls (segmented subnets...).
For tutorials we could by default use ZooServer running on
disco.ecf-project.org and move LAN based Disco to an advanced section.
ZooServer though has the disadvantage that it requires an additional
property to be set (hostname of ZooServer).
Yes. I don't care that much which discovery is used...although for
this tutorial (first OSGi remote service), I wanted to have no
configuration at all necessary just to do localhost/LAN-based usage.
- Launch configs are so Eclipse/PDE specific. To better integrate with
e.g. bndtools we might wanna abstract away launch configs. Being
specific is important for a good tutorial though.
Yeah. I don't particularly like launch configs either...but
bnd/bndtools is currently a whole lot of other install, config, tooling
differences...that would increase the complexity of this tutorial
significantly, IMHO (e.g. tool-specific meta-data...bnd.bnd, etc). I
would rather not have this tutorial turn into 'how to use bndtools to
create and run a simple example'...and I don't see how to avoid that
currently.
I agree that we have to do something to help with the tooling issues
involved in developing and testing OSGi bundles. Unfortunately, I
think this is one of OSGi Remote Service's (not just ECF) biggest
problems WRT understanding and adoption...and I/we are somewhat limited
in what we can directly do about it. I'm open to suggestions.
Scott
