On Mon, Mar 22, 2010 at 10:08, Felix Meschberger <fmesc...@gmail.com> wrote:
> Hi, > > On 22.03.2010 09:35, Guillaume Nodet wrote: > > On Mon, Mar 22, 2010 at 09:08, Felix Meschberger <fmesc...@gmail.com> > 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 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. > > 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
