Yeah, I missed the fact that the framework export the osgi bundles, so that bnd actually put those in the jar. However, I've just spotted that a wrong version of the tracker package is used. We still point to the old version instead of including the new BundleTracker stuff.
On Wed, Jun 10, 2009 at 01:12, Richard S. Hall<he...@ungoverned.org> wrote: > On 6/9/09 5:45 PM, Guillaume Nodet wrote: >> >> I heard that for the compendium spec. But iirc, the idea was to >> include each part of the spec in the implementation bundle. >> What about doing the same for core ? i.e. include the core osgi api >> inside the framework jar. That would remove some potential problem >> where user need to find the corresponding version of the api somewhere >> else ... >> > > Yep. > > We do embed the OSGi API needed by the framework (+ service tracker) into > the framework JAR. We will continue to do this. I just mean there will be no > separate OSGi JARs released by us anymore...and we likely can delete the > source from our repo if the official JARs are put into a maven repo some > place. > > -> richard > >> On Tue, Jun 9, 2009 at 23:13, Richard S. Hall<he...@ungoverned.org> >> wrote: >> >>> >>> On 6/9/09 4:52 PM, Guillaume Nodet wrote: >>> >>>> >>>> The only dependency is on the ServiceException which is part of 4.2. >>>> I guess we can use a snapshot of the osgi api for now. >>>> Btw, is there any location where such snapshots are deployed ? I >>>> haven't found any recent build on >>>> http://people.apache.org/repo/m2-snapshot-repository >>>> >>>> >>> >>> We don't plan on publishing the OSGi APIs any more, nor am I aware of >>> anyone >>> who does. The R4.2 JAR should go final and be made public any day now, so >>> we >>> won't have to wait too long and then someone can put it in a repo some >>> place. >>> >>> Regarding the ServiceException, that is in trunk now. >>> >>> -> richard >>> >>> >>>> >>>> On Tue, Jun 9, 2009 at 22:24, Richard S. Hall<he...@ungoverned.org> >>>> wrote: >>>> >>>> >>>>> >>>>> On 6/9/09 4:11 PM, Guillaume Nodet wrote: >>>>> >>>>> >>>>>> >>>>>> I'm maintaing locally a git branch of karaf which uses blueprint >>>>>> instead of spring-dm. The blueprint implementation is a bit more >>>>>> mature / stable now and I think it would be a good idea to switch. >>>>>> That said, we should also provide a feature to allow spring-dm powered >>>>>> bundles to be deployed. There are still a couple of things to do (fix >>>>>> the integration tests, display back spring-dm bundles in osgi/list >>>>>> command if spring-dm is installed), but my branch does not seem too >>>>>> broken. >>>>>> >>>>>> The only drawback I can see is that blueprint will depend on OSGi 4.2 >>>>>> (the current implementation has hacked the only dep on 4.2 so that it >>>>>> can run on the latest felix release). I've seen the api has been >>>>>> updated, so maybe we can depend on a felix snapshot for now. >>>>>> >>>>>> >>>>>> >>>>> >>>>> What 4.2 dependencies? The Felix 2.0.0 release should include the R4.2 >>>>> API >>>>> as you've already noticed, so this shouldn't be an issue, but if you >>>>> need >>>>> something specific implemented, we should try to coordinate that... >>>>> >>>>> -> richard >>>>> >>>>> >>>>>> >>>>>> So i'd like to commit the changes I have locally to avoid doing that >>>>>> in the dark for too long a time. Thoughts ? >>>>>> >>>>>> On Tue, Apr 28, 2009 at 15:45, Guillaume Nodet<gno...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> The past days, I've been working on the blueprint implementation >>>>>>> inside Geronimo [1]. >>>>>>> The spec is still being written so the implementation is not really >>>>>>> stable and is still missing a lot of features. >>>>>>> However, it's already somewhat usable and as I've hacked Karaf to >>>>>>> start using blueprint instead of spring-dm in a branch [2]. >>>>>>> Tests do not even compile, but I've been able to start the console, >>>>>>> so >>>>>>> I thought I would talk about it a bit. >>>>>>> >>>>>>> This raises the question whether we want to switch to blueprint >>>>>>> instead of spring-dm. >>>>>>> I think we should, and even have to, given that Spring-DM will >>>>>>> switch >>>>>>> to support Blueprint at some point in the future too. Also the >>>>>>> blueprint spec is way better than spring-dm wrt to namespace handlers >>>>>>> (that are considered dependencies, so we would not have problems with >>>>>>> namespace handlers not being available when a bundle is started) and >>>>>>> classloading (i think classes loaded for namespace handlers will be >>>>>>> loaded from the namespace handler bundle, thus freeing the bundle to >>>>>>> import all the namespace handlers packages), though those areas are >>>>>>> in >>>>>>> flux. >>>>>>> >>>>>>> If so, we might even want to do that before renaming the packages, as >>>>>>> the patch is quite big and would be quite broken after the rename >>>>>>> imho >>>>>>> ... >>>>>>> >>>>>>> As for tests, we'd have to switch to something else, which could be >>>>>>> junit4osgi from iPojo or pax-exam for example. >>>>>>> >>>>>>> Feedback welcome. >>>>>>> >>>>>>> [1] https://svn.apache.org/repos/asf/geronimo/sandbox/blueprint >>>>>>> [2] >>>>>>> >>>>>>> https://svn.apache.org/repos/asf/felix/sandbox/gnodet/karaf-blueprint/ >>>>>>> >>>>>>> -- >>>>>>> Cheers, >>>>>>> Guillaume Nodet >>>>>>> ------------------------ >>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>> ------------------------ >>>>>>> Open Source SOA >>>>>>> http://fusesource.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >> >> >> >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
