Ok, can you or somebody else have a look at FELIX-5548 and see if that is a blocker for a resolver release or no?
regards, karl On Tue, Feb 14, 2017 at 5:59 PM, Thomas Watson <[email protected]> wrote: > Yes, the resolver is ready to release. > > Tom > > On Tue, Feb 14, 2017 at 9:37 AM, Karl Pauls <[email protected]> wrote: > >> Well, I guess I don't even have to make the method public - I'm just >> going to copy it over to the framework if need be until we have a >> better way. >> >> With that out of the way, do you think the resolver is good to go for a >> release? >> >> regards, >> >> Karl >> >> On Tue, Feb 14, 2017 at 4:24 PM, Karl Pauls <[email protected]> wrote: >> >> That is currently a private static method. If the Felix framework does >> not >> >> already have the substitution wire information available then we can >> >> consider making this static method public so you can call it from your >> >> FelixResolveContext implementation. But I think if you don't already >> have >> >> this information calculated for resolved wirings then you likely have a >> bug >> >> in require-bundle class loader delegation. >> > >> > Afaik, we don't have this info readily available as we keep track of >> > this in a different way (I'll double-check with Richard). >> > >> > If not, I still would like to get a combined resolver and framework >> > release done this week so assuming I make the method public and >> > delegate to it from the framework do you think there is anything else >> > that would prevent us from doing a resolver and framework release? >> > >> > regards, >> > >> > Karl >> > >> >> My hope is that in a future OSGi Resolver specification the >> ResolveContext >> >> API from OSGi will contain updates that make the FelixResolveContext >> >> interface obsolete. For example, the proposed updates for the R7 >> resolver >> >> already remove the need for the method >> >> FelixResolveContext.getOndemandResources(Resource). >> >> >> >> Tom. >> >> >> >> >> >> On Mon, Feb 13, 2017 at 10:13 AM, Pierre De Rop <[email protected] >> > >> >> wrote: >> >> >> >>> Hi All, >> >>> >> >>> I also would like to do a test with the latest framework and resolver >> from >> >>> the trunk, but it looks like there is a compilation issue with the >> >>> framework (trunk): >> >>> >> >>> I have rebuilt the resolver, then the framework, and I'm having this >> error: >> >>> >> >>> [ERROR] >> >>> /tmp/xx/framework/src/main/java/org/apache/felix/ >> >>> framework/ResolveContextImpl.java:[44,8] >> >>> org.apache.felix.framework.ResolveContextImpl is not abstract and >> does not >> >>> override abstract method getSubstitutionWires(org.osgi.resource.Wiring) >> in >> >>> org.apache.felix.resolver.FelixResolveContext >> >>> >> >>> can someone please check this ? >> >>> >> >>> I just came across a NPE in the resolver using framework 5.6.1 and I >> would >> >>> like to check if I'm also having it with the latest resolver from the >> >>> trunk; thank you. >> >>> >> >>> best regards >> >>> /Pierre >> >>> >> >>> >> >>> On Mon, Feb 13, 2017 at 10:48 AM, Guillaume Nodet <[email protected]> >> >>> wrote: >> >>> >> >>> > Great ! >> >>> > Let me know if you need any help... >> >>> > >> >>> > Cheers, >> >>> > Guillaume >> >>> > >> >>> > 2017-02-10 12:53 GMT+01:00 Karl Pauls <[email protected]>: >> >>> > >> >>> > > I can do the release next week if you don't mind, as I was >> planning to >> >>> > > do a framework release anyhow (almost done with FELIX-5528 - just >> need >> >>> > > a bit more testing). >> >>> > > >> >>> > > regards, >> >>> > > >> >>> > > Karl >> >>> > > >> >>> > > On Fri, Feb 10, 2017 at 8:43 AM, Guillaume Nodet < >> [email protected]> >> >>> > > wrote: >> >>> > > > I'd like to get FELIX-5450 and FELIX-5514 out of the door, so >> unless >> >>> > > > someone volunteer to do the resolver 1.10.2 release, i'll give >> it a >> >>> > try >> >>> > > > next week. >> >>> > > > >> >>> > > > Cheers, >> >>> > > > Guillaume >> >>> > > >> >>> > > >> >>> > > >> >>> > > -- >> >>> > > Karl Pauls >> >>> > > [email protected] >> >>> > > >> >>> > >> >>> > >> >>> > >> >>> > -- >> >>> > ------------------------ >> >>> > Guillaume Nodet >> >>> > >> >>> >> > >> > >> > >> > -- >> > Karl Pauls >> > [email protected] >> >> >> >> -- >> Karl Pauls >> [email protected] >> -- Karl Pauls [email protected]
