[Karaf] Switching to blueprint ...
As you may have noticed by the recent commits, I've just upgrade Karaf to blueprint. Spring and Spring-DM are now available as features to be installed, but are not installed by default. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
OSGi 4.2 (was Re: [Karaf] Switching to blueprint ...)
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. Hallhe...@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. Hallhe...@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. Hallhe...@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 Nodetgno...@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
Re: OSGi 4.2 (was Re: [Karaf] Switching to blueprint ...)
On 6/10/09 2:34 AM, Guillaume Nodet wrote: 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. The compendium is not released yet, so I didn't update it. Plus, it was not necessarily clear that BundleTracker would be included in framework or not. - richard On Wed, Jun 10, 2009 at 01:12, Richard S. Hallhe...@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. Hallhe...@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. Hallhe...@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 Nodetgno...@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:
Re: [Karaf] Switching to blueprint ...
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. 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 Nodetgno...@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
Re: [Karaf] Switching to blueprint ...
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 Nodetgno...@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
Re: [Karaf] Switching to blueprint ...
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 On Tue, Jun 9, 2009 at 22:24, Richard S. Hallhe...@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 Nodetgno...@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
Re: [Karaf] Switching to blueprint ...
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. Hallhe...@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 Nodetgno...@gmail.comwrote: 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
Re: [Karaf] Switching to blueprint ...
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 ... On Tue, Jun 9, 2009 at 23:13, Richard S. Hallhe...@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. Hallhe...@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 Nodetgno...@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
Re: [Karaf] Switching to blueprint ...
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. Hallhe...@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. Hallhe...@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 Nodetgno...@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
Re: [Karaf] Switching to blueprint ...
Cool. Just one question though. How difficult would it be to run the tests in the same JVM in an isolated classloader ? It would make debugging way easier than having to hack the test to add the necessary jvm option for remote debugging. 2009/4/29 Alin Dreghiciu adreghi...@gmail.com: About tests, afaik iPojo will move also towards Pax Exam. We are discussing with Clement about doing the necessary changes in Pax Exam to support all features required by iPojo tests which were available in junit4osgi. On Tue, Apr 28, 2009 at 4:45 PM, 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 -- Alin Dreghiciu http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software. http://www.qi4j.org - New Energy for Java - Domain Driven Development. Looking for a job. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [Karaf] Switching to blueprint ...
The separate VM is a followup of our default Pax Runner based TestContainer implementation. As such, there can be (many) different TestContainer implementations. Its just a matter of convinience you lose when not using the pax runner richness. If there is demand for a native felix testcontainer, we could do so in quite a short amount of time. Toni On Wed, Apr 29, 2009 at 9:01 AM, Guillaume Nodet gno...@gmail.com wrote: Cool. Just one question though. How difficult would it be to run the tests in the same JVM in an isolated classloader ? It would make debugging way easier than having to hack the test to add the necessary jvm option for remote debugging. 2009/4/29 Alin Dreghiciu adreghi...@gmail.com: About tests, afaik iPojo will move also towards Pax Exam. We are discussing with Clement about doing the necessary changes in Pax Exam to support all features required by iPojo tests which were available in junit4osgi. On Tue, Apr 28, 2009 at 4:45 PM, 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 -- Alin Dreghiciu http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software. http://www.qi4j.org - New Energy for Java - Domain Driven Development. Looking for a job. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Toni Menzel Independent Software Developer - Looking for new projects! Professional Profile: http://www.osgify.com Blog: tonitcom.blogspot.com t...@okidokiteam.com http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software.
Re: [Karaf] Switching to blueprint ...
On 29.04.2009, at 09:08, Toni Menzel wrote: The separate VM is a followup of our default Pax Runner based TestContainer implementation. As such, there can be (many) different TestContainer implementations. Its just a matter of convinience you lose when not using the pax runner richness. If there is demand for a native felix testcontainer, we could do so in quite a short amount of time. Yes, there is a demand :-). As you know, I did some test with pax-exam. I find it pretty cool, but my main issue is that it dramatically slow... For example, running 2000 test case with junit4osgi (same VM isolated classloader) takes around 5 minutes 20 tests with pax:exam and the pax-runner container takes around 3 minutes. I agree that sometimes having a separated VM is great to avoid side- effects... But providing an alternative would be great: -(sometimes we're looking about side effects), but of course I have ideas about that that we can discuss (playing with test suite, were each test suite run it's own OSGi container...). Clement Toni On Wed, Apr 29, 2009 at 9:01 AM, Guillaume Nodet gno...@gmail.com wrote: Cool. Just one question though. How difficult would it be to run the tests in the same JVM in an isolated classloader ? It would make debugging way easier than having to hack the test to add the necessary jvm option for remote debugging. 2009/4/29 Alin Dreghiciu adreghi...@gmail.com: About tests, afaik iPojo will move also towards Pax Exam. We are discussing with Clement about doing the necessary changes in Pax Exam to support all features required by iPojo tests which were available in junit4osgi. On Tue, Apr 28, 2009 at 4:45 PM, 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 -- Alin Dreghiciu http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software. http://www.qi4j.org - New Energy for Java - Domain Driven Development. Looking for a job. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Toni Menzel Independent Software Developer - Looking for new projects! Professional Profile: http://www.osgify.com Blog: tonitcom.blogspot.com t...@okidokiteam.com http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software.
Re: [Karaf] Switching to blueprint ...
ok, we will have a solution tracked with this item: http://issues.ops4j.org/browse/PAXEXAM-79 On Wed, Apr 29, 2009 at 10:02 AM, Clement Escoffier clement.escoff...@gmail.com wrote: On 29.04.2009, at 09:08, Toni Menzel wrote: The separate VM is a followup of our default Pax Runner based TestContainer implementation. As such, there can be (many) different TestContainer implementations. Its just a matter of convinience you lose when not using the pax runner richness. If there is demand for a native felix testcontainer, we could do so in quite a short amount of time. Yes, there is a demand :-). As you know, I did some test with pax-exam. I find it pretty cool, but my main issue is that it dramatically slow... For example, running 2000 test case with junit4osgi (same VM isolated classloader) takes around 5 minutes 20 tests with pax:exam and the pax-runner container takes around 3 minutes. I agree that sometimes having a separated VM is great to avoid side-effects... But providing an alternative would be great: -(sometimes we're looking about side effects), but of course I have ideas about that that we can discuss (playing with test suite, were each test suite run it's own OSGi container...). Clement Toni On Wed, Apr 29, 2009 at 9:01 AM, Guillaume Nodet gno...@gmail.com wrote: Cool. Just one question though. How difficult would it be to run the tests in the same JVM in an isolated classloader ? It would make debugging way easier than having to hack the test to add the necessary jvm option for remote debugging. 2009/4/29 Alin Dreghiciu adreghi...@gmail.com: About tests, afaik iPojo will move also towards Pax Exam. We are discussing with Clement about doing the necessary changes in Pax Exam to support all features required by iPojo tests which were available in junit4osgi. On Tue, Apr 28, 2009 at 4:45 PM, 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 -- Alin Dreghiciu http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software. http://www.qi4j.org - New Energy for Java - Domain Driven Development. Looking for a job. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Toni Menzel Independent Software Developer - Looking for new projects! Professional Profile: http://www.osgify.com Blog: tonitcom.blogspot.com t...@okidokiteam.com http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software. -- Toni Menzel Independent Software Developer - Looking for new projects! Professional Profile: http://www.osgify.com Blog: tonitcom.blogspot.com t...@okidokiteam.com http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software.
Re: [Karaf] Switching to blueprint ...
I think moving to blueprint is great particularly if the r4.2 spec release is imminent. It seems like it should be getting close since it has moved to public draft recently, but I am not sure if there is an ETA. I'm sure someone here is plugged in to that process ;-) Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Directory Server :: http://directory.apache.org 2009/4/28 Richard S. Hall he...@ungoverned.org Well, if you are going to switch, now seems like the time. - richard On 4/28/09 9:45 AM, Guillaume Nodet 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/
Re: [Karaf] Switching to blueprint ...
Well, if you are going to switch, now seems like the time. - richard On 4/28/09 9:45 AM, Guillaume Nodet 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/
