| 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
 
 
 |