Hi Peter,
After thinking about this a little bit, I believe I have more of
an explanation for what's going on with you/your use case. In
short, I think it comes down to this:
On 3/11/2015 3:10 AM, Peter Hermsdorf wrote:
<stuff deleted>
Realistically, it might become
difficult/impossible to support ECF 3.7 on Indigo for much
longer...and I *believe* that ECF 3.9.3 will run on everything
back to Kepler (although I admit I haven't tested on Kepler
yet...I will do so/help do so, however, if that is necessary.
Please let me know). The dependency here is on the use of the
OSGI Wiring API (required for compliance with modern versions
of OSGi RSA spec), which I *think* only appeared in Kepler
version of Equinox (can't remember what number version of
Equinox that was right now).
Of course thats a problem. I tried upgrading to the latest
version, but as you already statet, there is a dependency to a
core equinox.osgi package version 1.7 whereas eclipse indigo
only has version 1.6 available.
An upgrade of our RCP app to Eclipse 4 is planned, but currently
not in work. I case we would need a fix in ECF 3.7 I would
consider patching/building it myself ....
i.e. the version of ECF RSA that you are using (ECF 3.7/Indigo)
was done prior to two changes that are affecting you:
1) It was prior to the OSGi RSA 1.1 specification, which required
reworking the use of the edef-given properties...for both
discovery and distribution/lookup/import on the consumer. The
reason this was necessary was that RSA 1.1 added the notion of a
remote service 'update' (i.e. updating the remote service's
properties), and so to do this with EDEF meant adding additional
properties, and more importantly, changing the semantics/handling
of endpointdescription equality. I now believe this is why my
initial response of making the endpoint.service.id unique in your
generated edef didn't for you, because you are using a version
prior to when this property (only) was used to determine ed
uniqueness.
2) Some changing (simplification, really) of use of ECF-specific
remote service properties. I can't immediately go into technical
detail here, as I have to remind myself about the specifics (I've
forgotten), but I'm pretty sure that that's this could be
affecting you/your use case as well.
IMHO there are two ways to deal with this:
1) Help you transition to ECF 3.9.3 (or something more recent from
ECF). One thing to consider: I'm pretty sure that ECF 3.9.3
will run properly on Equinox Kepler or later, and I believe that
Kepler had/has support for RCP 3.8 (as opposed to requiring that
you move to Eclipse 4.x immediately).
2) As you say above, we could look to apply a 'fix' to ECF 3.7
(what you are experiencing may not actually be a bug in 3.7, but
rather simply not yet applying the right set of remote service
property values...I'm not sure at this point). I will help with
this if you so desire, but as you might expect I'm not anxious to
do this...i.e. I would prefer 1. Why? Two reasons: a) Moving
forward it's simpler for ECF; b) When you move to something more
recent in terms of ECF versions it would be better if you didn't
have to rework your edef in addition to adjusting to the UI and
other changes.
I'm willing to help with either 1 or 2 based upon what you decide,
but I'm limited by resources (my time).
To help me figure out what would be involved with 2, would you let
me know what the exact version of ECF you are using is? (i.e.
with qualifier)
Thanks,
Scott
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
|
