[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] NullpointerException in RemoteServiceAdmin


On Fri, 28 Sep 2018 at 17:42, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
On 9/28/2018 4:03 AM, Peter Hermsdorf wrote:
>
> Hi Scott,
>
> thanks (again) for fixing the issue with the serialization. I finally
> could upgrade to ECF 3.14.1 with the additional bundles from the
> snapshot build with the 3 bug fixes. I haven't observed any additional
> issues - nor the test suite.
>
> Just one more thing: when building the product i stumbled across the
> following error:
>
> org.eclipse.ecf.remoteservice.feature.feature.group
> 2.5.0.v20180409-2248 depends on:
> org.eclipse.ecf.remoteservice.asyncproxy [2.1.0.v20180409-2248]
>
> Maybe it would be possible to define that dependency as optional as
> addition to bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=539469 .
>

I'm not sure. I don't immediately know how we would have the feature
optionally include the 2.1 and 1.1 bundles. Â One or the other are
required, based upon the dependencies as Peter points out. Â Mat:Â do
you know how to do that?

Hmm, I'm not sure you can. Eclipse "features" are kind of a hacky hold-over from the pre-OSGi days...

I think the easiest way to workaround this would be not to include the "o.e.ecf.remoteservice.feature" feature in one's product definition, but rather simply include the "o.e.ecf.remoteservice" bundle and the "o.e.ecf.remoteservice.asyncproxy" version of your choice instead.

Alternatively, since the "o.e.ecf.remoteservice" bundle already expresses a non-optional dep on the "o.e.ecf.remoteservice.asyncproxy" bundle with a sufficiently broad version range that either bundle can satisfy the dep -- is it even necessary specify the asyncproxy bundles in the feature definition? In theory you could remove them from the feature definition and Eclipse should still do the Right Thingâ when you install it.

Alternatively alternatively, there appears to be some p2 black magic that can be employed to workaround the limitations of feature manifests. According to the documentation [1] you could, in theory, have a p2.inf file co-located with the feature.xml containing something like this:

requires.0.namespace = org.eclipse.equinox.p2.iu
requires.0.name = org.eclipse.ecf.remoteservice.asyncproxy
requires.0.version = 1.1.100
requires.0.optional = true
requires.1.namespace = org.eclipse.equinox.p2.iu
requires.1.name = org.eclipse.ecf.remoteservice.asyncproxy
requires.1.version = 2.1.0
requires.1.optional = true

And that should augment the requirements generated for the feature IU, but I haven't tried it yet.


Â

Feel free to open a releng bug for this...we will try to address it, but
I'm not sure how.

BTW:ÂÂ I've been contemplating releasing 3.14.3 and with this most
recent bug fix it seems time to do so. Any comments?

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