On Mon, Mar 22, 2010 at 12:23, Felix Meschberger <[email protected]> wrote:
> Hi, > > On 22.03.2010 11:23, Guillaume Nodet wrote: > > On Mon, Mar 22, 2010 at 10:36, Felix Meschberger <[email protected]> > wrote: > > > >> Hi, > >> > >> On 22.03.2010 10:17, Guillaume Nodet wrote: > >>> On Mon, Mar 22, 2010 at 10:08, Felix Meschberger <[email protected]> > >> wrote: > >>> > >>>> Hi, > >>>> > >>>> On 22.03.2010 09:35, Guillaume Nodet wrote: > >>>>> On Mon, Mar 22, 2010 at 09:08, Felix Meschberger <[email protected] > > > >>>> wrote: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> The bundlerepository bundle has been disbanded into the core > >>>>>> bundlerepository stuff and the Manifest parsing stuff moved to the > new > >>>>>> commons library/project. > >>>>>> > >>>>>> This creates some grieve for downstream users like Web Console but > >> also > >>>>>> other users of the bundlrepository. > >>>>>> > >>>>> > >>>>> How so ? The bundlerepository bundle is supposed to embed those > >>>>> dependencies, it should not affect the users at all. Or is that > >> because > >>>> the > >>>>> web console was depending on those internal classes that have been > >>>>> refactored ? > >>>> > >>>> Actually, I missed the point that old API is still supported ... > Sorry. > >>>> > >>>> So, no problems. > >>>> > >>>> Still, the plugin should of course be able to cope with the situation > >>>> where only the old API is available. > >>>> > >>> > >>> Yeah, that'd be nice. It might require a bit more work and some > features > >>> might be disabled. For example, computing the dependencies would not > be > >> a > >>> good idea i think because it might take a very long time. > >> > >> What dependencies to compute ? Do you mean the optional > >> dependencies/requirements ? > >> > > > > Yes. I think wit the previous version of the resolver, it would to > > unnacceptable computation time for the web pages (if you have a repo of a > > decent size), especially as you have no way to not compute optional > > dependencies and those are wrongly marked as mandatory anyway. The new > one > > being 10 time faster leads to better results. > > > > > >> > >>> > >>> What if we resurrect the old version of the plugin and use it if the > new > >> api > >>> is not available ? > >>> I.e. we would have both plugins and use the new one if possible or the > >> old > >>> one if not. > >> > >> I am trying to implement this right now. > >> > >> Nevertheless this would leave us with the SNAPSHOT dependency to the new > >> API, which prevents the Web Console from being released at this time. > >> > >> How about just supporting the old API for now and for a next release > >> provide a second plugin implementation supporting the new functionality > >> of the new API ? > >> > >> > > Yeah, or we would release bundlerepository now. That would be a good > idea > > anyway I think. > > Plus the new utils ? > Yes > > BTW: I am able to implement support for both the old OSGi API and the > new Felix API ... So we would be in good shape in this respect. > > If you feel comfortable with the state of the bundlerepository and utils > projects, I could include them in my webconsole 3.0 release batch. > > WDYT ? > Sounds good to me. > > Regards > Felix > > > > > > >> Regards > >> Felix > >>> > >>> > >>>> > >>>> Regards > >>>> Felix > >>>> > >>>>> > >>>>> > >>>>>> > >>>>>> As for the Web Console, I think we should move the OBR support > plugin > >>>>>> out of the Web Console over to the bundlerepository plugin. This > >> solves > >>>>>> the more general problem of the current bundlerepository refactoring > >> for > >>>>>> the web console (and only for the web console). > >>>>>> > >>>>>> The more general problem is that of removing existing API: The old > >>>>>> org.osgi.service.obr API has been replaced in the bundle repository > >>>>>> trunk by the new o.a.felix.bundlerepository API. There may be very > >> good > >>>>>> reasons to do this. But it leeaves current users of the o.o.s.obr > API > >>>>>> out in the dark. > >>>>>> > >>>>> > >>>>> Not really. The bundlerepository has a "compatibility layer" that is > >>>>> installed if the o.o.os.obr API is installed. Currently is not > bundled > >>>>> anymore, but if we change that, it should be almost transparent for > >>>> users. > >>>>> > >>>>>> > >>>>>> WDYT of moving the obr bundle ? In the short term this looks to my > >> like > >>>>>> the only feasible solution to be able to cut a Web Console release > >> soon. > >>>>>> > >>>>>> What do we do about the now missing API ? To we provide backwards > >>>>>> compatible wrappers (including an o.o.service.obr.RepositoryAdmin > >>>>>> service) ? Do we simply abandon the old API and raise the bundle > >>>>>> repository bundle to a new major version number ? > >>>>>> > >>>>> > >>>>> Currently we have the wrappers already. if you installed the old obr > >> api > >>>>> first, the service should be registered. > >>>>> > >>>>> > >>>>> > >>>>>> Regards > >>>>>> Felix > >>>>>> > >>>>>> On 21.03.2010 04:27, Sahoo wrote: > >>>>>>> This failure is introduced in rev #925279. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Sahoo > >>>>>>> > >>>>>>> Sahoo wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> After updating my workspace to svn rev#925708, I am doing a clean > >>>>>>>> build and I see compilation failures like this: > >>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >> > /src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java:[904,54] > >>>>>>>> cannot find symbol > >>>>>>>> [exec] symbol: class R4Package > >>>>>>>> / > >>>>>>>> I don't see any R4Package.class in > >>>>>>>> bundlerepository-1.5.0-SNAPSHOT.jar, that's recently built. > >>>>>>>> > >>>>>>>> Is there a continuous integration job running for trunk? Can I see > >> its > >>>>>>>> log? > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Sahoo > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >>> > >> > > > > > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
