Community
Participate
Working Groups
Description Resource Path Location Type The method getServiceReferences(String, String) is ambiguous for the type BundleContext Activator.java /org.eclipse.ecf.osgi.services.distribution/src/org/eclipse/ecf/internal/osgi/services/distribution line 190 Java Problem The method getServiceReferences(String, String) is ambiguous for the type BundleContext RemoteOSGiServiceImpl.java /ch.ethz.iks.r_osgi.remote/src/main/java/ch/ethz/iks/r_osgi/impl line 982 Java Problem The method registerService(String, Object, Dictionary<String,?>) in the type BundleContext is not applicable for the arguments (String, AbstractEndpointDescriptionFactory, Properties) Activator.java /org.eclipse.ecf.osgi.services.remoteserviceadmin/src/org/eclipse/ecf/internal/osgi/services/remoteserviceadmin line 101 Java Problem The method registerService(String, Object, Dictionary<String,?>) in the type BundleContext is not applicable for the arguments (String, AbstractServiceInfoFactory, Properties) Activator.java /org.eclipse.ecf.osgi.services.remoteserviceadmin/src/org/eclipse/ecf/internal/osgi/services/remoteserviceadmin line 98 Java Problem The method registerService(String, Object, Dictionary<String,?>) in the type BundleContext is not applicable for the arguments (String, Hello, Properties) HelloHostApplication.java /org.eclipse.ecf.examples.remoteservices.hello.host/src/org/eclipse/ecf/internal/examples/remoteservices/hello/host line 82 Java Problem The method registerService(String, Object, Dictionary<String,?>) in the type BundleContext is not applicable for the arguments (String, ServicePublication, Properties) PublishTest.java /org.eclipse.ecf.tests.osgi.services.discovery/src/org/eclipse/ecf/tests/osgi/services/discovery line 81 Java Problem The method registerService(String[], Object, Dictionary<String,?>) in the type BundleContext is not applicable for the arguments (String[], Object, Properties) AbstractDistributionTest.java /org.eclipse.ecf.tests.osgi.services.distribution/src/org/eclipse/ecf/tests/osgi/services/distribution line 164 Java Problem The method registerService(String[], Object, Dictionary<String,?>) in the type BundleContext is not applicable for the arguments (String[], ZooDiscoveryContainer, Properties) DiscoveryActivator.java /org.eclipse.ecf.provider.zookeeper/src/org/eclipse/ecf/provider/zookeeper line 51 Java Problem The type RemoteFilterImpl must implement the inherited abstract method Filter.matches(Map) RemoteFilterImpl.java /org.eclipse.ecf.provider.r_osgi/src/org/eclipse/ecf/internal/provider/r_osgi line 22 Java Problem The type RemoteFilterImpl must implement the inherited abstract method Filter.matches(Map) RemoteFilterImpl.java /org.eclipse.ecf.provider.remoteservice/src/org/eclipse/ecf/provider/remoteservice/generic line 23 Java Problem The type RemoteFilterImpl must implement the inherited abstract method Filter.matches(Map<String,?>) RemoteFilterImpl.java /org.eclipse.ecf.remoteservice/src/org/eclipse/ecf/remoteservice/util line 25 Java Problem
Reproducible with a recent Indigo I-build (e.g. I20100921-1024)
I had heard that Indigo had/has moved over to using the generics/1.5 support. It is going to take a little while to get on that stream (and of course it means complicating our own build for supporting old streams.
(In reply to comment #2) > (and of course it > means complicating our own build for supporting old streams. Why is that?
(In reply to comment #3) > (In reply to comment #2) > > (and of course it > > means complicating our own build for supporting old streams. > > Why is that? We'll have to be able to build something that runs on both 3.6 and Indigo streams...on vms down to 1.4 (i.e. without generics support). I suppose we can do the same thing we're doing in org.eclipse.ecf.remoteservice bundle...i.e. to use generics/1.5 for compile but make the javacTarget=1.4. Which is what Equinox is doing also, I believe.
The only problem for which I don't see a fix out of my head is: The type RemoteFilterImpl must implement the inherited abstract method Filter.matches(Map<String,?>) RemoteFilterImpl.java /org.eclipse.ecf.remoteservice/src/org/eclipse/ecf/remoteservice/util line 25 Java Problem On r4.3 we can simply delegate to filter.matches(Map), but on <= r4.2 that method does not exist and thus causes a compiler error.
(In reply to comment #5) > The only problem for which I don't see a fix out of my head is: > > The type RemoteFilterImpl must implement the inherited abstract method > Filter.matches(Map<String,?>) RemoteFilterImpl.java > /org.eclipse.ecf.remoteservice/src/org/eclipse/ecf/remoteservice/util line > 25 Java Problem > > On r4.3 we can simply delegate to filter.matches(Map), but on <= r4.2 that > method does not exist and thus causes a compiler error. Never mind, converting the map into a dict and delegating to matchCase(Dictionary) should do the trick.
Fixed in master If we want this in 3.4.1 too, we would have accept o.e.e.remoteservices 5.1.0 in a service release due to API addition org.eclipse.ecf.remoteservice.util.RemoteFilterImpl.matches(Map)
(In reply to comment #7) > Fixed in master > If we want this in 3.4.1 too, we would have accept o.e.e.remoteservices 5.1.0 > in a service release due to API addition > org.eclipse.ecf.remoteservice.util.RemoteFilterImpl.matches(Map) I would have no problem with trying to get a waiver from the API police/PMC for this to include in 3.4.1. One question: I haven't tested everything, but I assume that there should be no problem in using released ECF 3.4.0 binaries on Indigo m3. True?
(In reply to comment #8) > One question: I haven't tested everything, but I assume that there should be > no problem in using released ECF 3.4.0 binaries on Indigo m3. True? I don't know either.
