felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: OBR Web Console Plugin
Date Mon, 22 Mar 2010 10:23:23 GMT
On Mon, Mar 22, 2010 at 10:36, Felix Meschberger <fmeschbe@gmail.com> wrote:

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


> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message