You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Felix Meschberger <fm...@gmail.com> on 2010/03/22 09:08:18 UTC
OBR Web Console Plugin (was: trunk/webconsole fails to build)
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.
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.
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 ?
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
>
Re: OBR Web Console Plugin
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Oops, it looks like the second problem has already been taken care of.
Sorry for the confusion.
Remains the first problem: moving the OBR stuff over to the
bundlerepository bundle.
Alternatively, the bundle could differentiate between the old API and
the newly provided API and provide more options in the latter case.
Regards
Felix
On 22.03.2010 09:08, Felix Meschberger 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.
>
> 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.
>
> 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 ?
>
> 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
>>
Updated proposed release list (was: OBR Web Console Plugin)
Posted by Felix Meschberger <fm...@gmail.com>.
Hi
On 22.03.2010 13:28, Guillaume Nodet wrote:
> On Mon, Mar 22, 2010 at 12:23, Felix Meschberger <fm...@gmail.com> wrote:
>> 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.
Good. So I will shoot for the following releases then:
Web Console 3.0.0
Event Plugin 1.0.2 (adapted for JQuery UI)
Memory Usage Plugin 1.0.0 (new plugin)
UPNP Plugin 1.0.0 (new plugin)
Bundle Repository 1.6.0 (required by Web Console, new API)
Utils 1.0.0 (required by Web Console)
Regards
Felix
Re: OBR Web Console Plugin
Posted by Guillaume Nodet <gn...@gmail.com>.
On Mon, Mar 22, 2010 at 12:23, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> On 22.03.2010 11:23, Guillaume Nodet wrote:
> > On Mon, Mar 22, 2010 at 10:36, Felix Meschberger <fm...@gmail.com>
> wrote:
> >
> >> Hi,
> >>
> >> On 22.03.2010 10:17, Guillaume Nodet wrote:
> >>> On Mon, Mar 22, 2010 at 10:08, Felix Meschberger <fm...@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.
>
> 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
Re: OBR Web Console Plugin
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 22.03.2010 11:23, Guillaume Nodet wrote:
> On Mon, Mar 22, 2010 at 10:36, Felix Meschberger <fm...@gmail.com> wrote:
>
>> Hi,
>>
>> On 22.03.2010 10:17, Guillaume Nodet wrote:
>>> On Mon, Mar 22, 2010 at 10:08, Felix Meschberger <fm...@gmail.com>
>> wrote:
>>>
>>>> Hi,
>>>>
>>>> On 22.03.2010 09:35, Guillaume Nodet wrote:
>>>>> On Mon, Mar 22, 2010 at 09:08, Felix Meschberger <fm...@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.
Plus the new utils ?
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 ?
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
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
Re: OBR Web Console Plugin
Posted by Guillaume Nodet <gn...@gmail.com>.
On Mon, Mar 22, 2010 at 10:36, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> On 22.03.2010 10:17, Guillaume Nodet wrote:
> > On Mon, Mar 22, 2010 at 10:08, Felix Meschberger <fm...@gmail.com>
> wrote:
> >
> >> Hi,
> >>
> >> On 22.03.2010 09:35, Guillaume Nodet wrote:
> >>> On Mon, Mar 22, 2010 at 09:08, Felix Meschberger <fm...@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
Re: OBR Web Console Plugin
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 22.03.2010 10:17, Guillaume Nodet wrote:
> On Mon, Mar 22, 2010 at 10:08, Felix Meschberger <fm...@gmail.com> wrote:
>
>> Hi,
>>
>> On 22.03.2010 09:35, Guillaume Nodet wrote:
>>> On Mon, Mar 22, 2010 at 09:08, Felix Meschberger <fm...@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 ?
>
> 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 ?
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
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
Re: OBR Web Console Plugin
Posted by Guillaume Nodet <gn...@gmail.com>.
On Mon, Mar 22, 2010 at 10:08, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> On 22.03.2010 09:35, Guillaume Nodet wrote:
> > On Mon, Mar 22, 2010 at 09:08, Felix Meschberger <fm...@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
Re: OBR Web Console Plugin
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 22.03.2010 09:35, Guillaume Nodet wrote:
> On Mon, Mar 22, 2010 at 09:08, Felix Meschberger <fm...@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.
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
>>>
>>
>
>
>
Re: OBR Web Console Plugin (was: trunk/webconsole fails to build)
Posted by Guillaume Nodet <gn...@gmail.com>.
On Mon, Mar 22, 2010 at 09:08, Felix Meschberger <fm...@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 ?
>
> 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