Re: Karaf and JRebel
Wow it's much more expensive than it was 5 years ago: https://zeroturnaround.com/software/jrebel/buy/ https://zeroturnaround.com/software/jrebel/buy/ -- View this message in context: http://karaf.922171.n3.nabble.com/Karaf-and-JRebel-tp4033487p4033489.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Karaf and JRebel
ok thx didn't know about dev:watch. -- View this message in context: http://karaf.922171.n3.nabble.com/Karaf-and-JRebel-tp4033487p4033490.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: complete OSGi bundle dependency tree
Hello, sorry for answering late, but the hawtio console has a plugin for visualizing bundle dependencies from a package and also a service perspective. These blog entries describe the plugin and also give you the pointers into the code. The hawtio rendering just uses the underlying REST interface provided by jolokia that is intalled with the hawtio feature. It should be straight forward to use the REST API for your purposes. [1] http://www.wayofquality.de/open%20source/hawtio/using-a-datafactory-in-hawtio/ [2] http://www.wayofquality.de/open%20source/hawtio/creating-a-hwatio-directive/ and of course [3] http://hawt.io/ Hope that helps Andreas On 21/05/14 10:19, Julio Carlos Barrera Juez wrote: Hello. I'm looking for a bundle or a tool that allows me to construct a complete bundle dependency tree of my OSGi system. I'm aware of Karaf command dev:show-tree [1] [2] [3], but I want something more general. Instead of getting bundle dependency tree of one bundle I want to have it for the entire platform, or al least I want to have the inverse command, it is, having bundles depending on one specified bundle. Moreover I want to use this information programmatically, not in a command or a graphical representation. I know I could develop it more or less using org.osgi.framework.wiring.BundleWiring [4], but I want to know if there is a bundle/tool doing this job now. I'm aware of tools like Eclipse PDE Incubator Dependency Visualization [5] and I'm working to extract core source code of it to use it. Any help or guidance would be really appreciated. Thank You. Regards, Julio. [1] dev:show-tree in Karaf 2.2.x - http://karaf.apache.org/manual/latest-2.2.x/commands/dev-show-tree.html [2] dev:show-tree in Karaf 2.3.x - http://karaf.apache.org/manual/latest-2.3.x/commands/dev-show-tree.html [3] bundle:tree-show in Karaf 3.0.x - http://karaf.apache.org/manual/latest/commands/bundle-tree-show.html [4] org.osgi.framework.wiring.BundleWiring - http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/wiring/BundleWiring.html [5] Eclipse PDE Incubator Dependency Visualization - http://www.eclipse.org/pde/incubator/dependency-visualization/getsource.php Julio C. Barrera Juez Office phone: +34 93 357 99 27 Distributed Applications and Networks Area (DANA) i2CAT Foundation, Barcelona, Spain http://dana.i2cat.net http://dana.i2cat.net/ -- Andreas Gies WoQ – Way of Quality UG Geschäftsführer CTO /eMail:/andr...@wayofquality.de mailto:andr...@wayofquality.de /Tel:/ +49 151 23470823 /Fax:/ +49 1805 006534 2114 /Twitter:/ andreasgies /Skype:/ giessonic /LinkedIn:/ http://de.linkedin.com/pub/andreas-gies/0/594/aa5/ (http://de.linkedin.com/pub/andreas-gies/0/594/aa5/) /Xing:/ http://www.xing.com/profile/Andreas_Gies (http://www.xing.com/profile/Andreas_Gies) /Blog:/ http://www.wayofquality.de/index.php/en/blog (http://www.wayofquality.de/index.php/en/blog) /Github:/ https://github.com/atooni (https://github.com/atooni) /Amtsgericht Landshut:/HRB 8352// // /Ust.-Id.:/ DE274771254 Haftungsausschluss Diese Email kann vertrauliche und/oder rechtlich geschützte Informationen enthalten und ist ausschließlich für den/die benannten Adressaten bestimmt. Sollten Sie nicht der beabsichtigte Empfänger sein oder diese Email irrtümlich erhalten haben, ist es Ihnen nicht gestattet diese Mail oder einen Teil davon ohne unsere Erlaubnis zu verbreiten, zu kopieren, unbefugt weiterzuleiten oder zu behalten. Informieren Sie bitte sofort den Absender telefonisch oder per Email und löschen Sie diese Email und alle Kopien aus Ihrem System. Wir haften nicht für die Unversehrtheit von Emails, nachdem sie unseren Einflussbereich verlassen haben. Disclaimer This email may contain confidential and/or privileged information and is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorized to and must not disclose, copy, distribute, or retain this message or any part of it without our authority. Please contact the sender by call or reply email immediately and destroy all copies and the original message. We are not responsible for the integrity of emails after they have left our sphere of control. //
Re: Karaf and JRebel
In fact if you are using maven (which I think you are), you can use something like: felix.fileinstall.dir = /full/path/to/your/module-project/target/ Then, when even you modify any class and it gets compiled by your ID, karaf will reload the module. Another open source similar to JRebel is https://github.com/fakereplace/fakereplace I didn't test it with Karaf (I didn't need to). On Fri, Jun 13, 2014 at 2:09 AM, asookazian2 asookaz...@gmail.com wrote: ok thx didn't know about dev:watch. -- View this message in context: http://karaf.922171.n3.nabble.com/Karaf-and-JRebel-tp4033487p4033490.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: complete OSGi bundle dependency tree
FYI, you can do quite the same with MBeans and Jolokia (directly). EIK is also usable in Eclipse. Programmatically, you can use the package/wiring service (it's what show-tree does). Regards JB On 06/13/2014 08:14 AM, Andreas Gies wrote: Hello, sorry for answering late, but the hawtio console has a plugin for visualizing bundle dependencies from a package and also a service perspective. These blog entries describe the plugin and also give you the pointers into the code. The hawtio rendering just uses the underlying REST interface provided by jolokia that is intalled with the hawtio feature. It should be straight forward to use the REST API for your purposes. [1] http://www.wayofquality.de/open%20source/hawtio/using-a-datafactory-in-hawtio/ [2] http://www.wayofquality.de/open%20source/hawtio/creating-a-hwatio-directive/ and of course [3] http://hawt.io/ Hope that helps Andreas On 21/05/14 10:19, Julio Carlos Barrera Juez wrote: Hello. I'm looking for a bundle or a tool that allows me to construct a complete bundle dependency tree of my OSGi system. I'm aware of Karaf command dev:show-tree [1] [2] [3], but I want something more general. Instead of getting bundle dependency tree of one bundle I want to have it for the entire platform, or al least I want to have the inverse command, it is, having bundles depending on one specified bundle. Moreover I want to use this information programmatically, not in a command or a graphical representation. I know I could develop it more or less using org.osgi.framework.wiring.BundleWiring [4], but I want to know if there is a bundle/tool doing this job now. I'm aware of tools like Eclipse PDE Incubator Dependency Visualization [5] and I'm working to extract core source code of it to use it. Any help or guidance would be really appreciated. Thank You. Regards, Julio. [1] dev:show-tree in Karaf 2.2.x - http://karaf.apache.org/manual/latest-2.2.x/commands/dev-show-tree.html [2] dev:show-tree in Karaf 2.3.x - http://karaf.apache.org/manual/latest-2.3.x/commands/dev-show-tree.html [3] bundle:tree-show in Karaf 3.0.x - http://karaf.apache.org/manual/latest/commands/bundle-tree-show.html [4] org.osgi.framework.wiring.BundleWiring - http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/wiring/BundleWiring.html [5] Eclipse PDE Incubator Dependency Visualization - http://www.eclipse.org/pde/incubator/dependency-visualization/getsource.php Julio C. Barrera Juez Office phone: +34 93 357 99 27 Distributed Applications and Networks Area (DANA) i2CAT Foundation, Barcelona, Spain http://dana.i2cat.net http://dana.i2cat.net/ -- Andreas Gies WoQ – Way of Quality UG Geschäftsführer CTO /eMail:/andr...@wayofquality.de mailto:andr...@wayofquality.de /Tel:/ +49 151 23470823 /Fax:/ +49 1805 006534 2114 /Twitter:/ andreasgies /Skype:/ giessonic /LinkedIn:/ http://de.linkedin.com/pub/andreas-gies/0/594/aa5/ (http://de.linkedin.com/pub/andreas-gies/0/594/aa5/) /Xing:/ http://www.xing.com/profile/Andreas_Gies (http://www.xing.com/profile/Andreas_Gies) /Blog:/ http://www.wayofquality.de/index.php/en/blog (http://www.wayofquality.de/index.php/en/blog) /Github:/ https://github.com/atooni (https://github.com/atooni) /Amtsgericht Landshut:/HRB 8352// // /Ust.-Id.:/ DE274771254 Haftungsausschluss Diese Email kann vertrauliche und/oder rechtlich geschützte Informationen enthalten und ist ausschließlich für den/die benannten Adressaten bestimmt. Sollten Sie nicht der beabsichtigte Empfänger sein oder diese Email irrtümlich erhalten haben, ist es Ihnen nicht gestattet diese Mail oder einen Teil davon ohne unsere Erlaubnis zu verbreiten, zu kopieren, unbefugt weiterzuleiten oder zu behalten. Informieren Sie bitte sofort den Absender telefonisch oder per Email und löschen Sie diese Email und alle Kopien aus Ihrem System. Wir haften nicht für die Unversehrtheit von Emails, nachdem sie unseren Einflussbereich verlassen haben. Disclaimer This email may contain confidential and/or privileged information and is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorized to and must not disclose, copy, distribute, or retain this message or any part of it without our authority. Please contact the sender by call or reply email immediately and destroy all copies and the original message. We are not responsible for the integrity of emails after they have left our sphere of control. // -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: OSGI and Spring
As an addition, you can always use Spring beans with Aries-bp, as you would do with any other bp bean. The only thing you cannot do without spring-dm/gemini is the use of Spring namespaces/annotations. I'm pretty sure it's relatively easy to bridge annotation support configuring the right Spring beans: I dropped my devs on it due to my ignorance (5 years ago) on an OSGI-ready Spring classpath scanner implementation. Best regards, 2014-06-12 23:21 GMT+02:00 Krzysztof Sobkowiak krzys.sobkow...@gmail.com: If many people still need a Spring integration with OSGi it should be no problem. ServiceMix Bundles sub-project provides now Spring bundles. We have also Eclipse Gemini Blueprint (successor of Spring DM), but I don't know how active the project is. But usage of Gemini for Spring integration forces usage of the Gemini's Blueprint implementation too. Personally I don't like such a configuration. I prefer usage of Spring DM which, I think so, doesn't need to die. Indeed it's died. But it can be reanimated and provide a lightweight Spring integration -- probably as a new project based on Spring DM code base. If people want (or need) to use Spring in OSGi there should be no problem. They must only invest some effort to make the Spring OSGi integration still living Best regards Krzysztof On 12.06.2014 22:57, Tim Jones wrote: I am adding a few URLs as I think it is will be of interest to others who are looking for direction re the future of Spring and OSGI -- Somehow I wonder how well future spring versions will behave in OSGi. I think we should start to at least warn our users that continued use of spring in OSGi is an increasing risk. http://karaf.922171.n3.nabble.com/Spring-OSGi-bundles-no-longer-being-released-td4031212.html -- Are we really going to let die the Spring integration with OSGi?http://karaf.922171.n3.nabble.com/Re-The-future-of-the-Spring-with-Fabric8-td4033455.html -- We should also make clear that Spring DM is dead. And that in general Spring on OSGi is not a good ideahttps://github.com/fabric8io/fabric8/issues/1634 -- View this message in context: http://karaf.922171.n3.nabble.com/OSGI-and-Spring-tp4033211p4033485.html Sent from the Karaf - User mailing list archive at Nabble.com. -- Krzysztof Sobkowiak JEE OSS Architect | Technical Architect @ Capgemini Capgemini http://www.pl.capgemini.com/ | Software Solutions Center http://www.pl.capgemini-sdm.com/ | Wroclaw e-mail: krzys.sobkow...@gmail.com | Twitter: @KSobkowiak Calendar: goo.gl/yvsebC -- Charlie Mordant Full OSGI/EE stack made with Karaf: https://github.com/OsgiliathEnterprise/net.osgiliath.parent
Re: OSGI and Spring
2014-06-13 10:02 GMT+02:00 Charlie Mordant cmorda...@gmail.com: As an addition, you can always use Spring beans with Aries-bp, as you would do with any other bp bean. There are two big limitations in Aries that makes reusing spring beans difficult: * FactoryBean are not supported * type based discovery is not supported So for beans that are somewhat tied to any spring api, it's not necessarily an easy task to migrate. The only thing you cannot do without spring-dm/gemini is the use of Spring namespaces/annotations. Namespaces are supported by spring-dm/gemini afaik. I'm pretty sure it's relatively easy to bridge annotation support configuring the right Spring beans: I dropped my devs on it due to my ignorance (5 years ago) on an OSGI-ready Spring classpath scanner implementation. Best regards, 2014-06-12 23:21 GMT+02:00 Krzysztof Sobkowiak krzys.sobkow...@gmail.com : If many people still need a Spring integration with OSGi it should be no problem. ServiceMix Bundles sub-project provides now Spring bundles. We have also Eclipse Gemini Blueprint (successor of Spring DM), but I don't know how active the project is. But usage of Gemini for Spring integration forces usage of the Gemini's Blueprint implementation too. Personally I don't like such a configuration. I prefer usage of Spring DM which, I think so, doesn't need to die. Indeed it's died. But it can be reanimated and provide a lightweight Spring integration -- probably as a new project based on Spring DM code base. If people want (or need) to use Spring in OSGi there should be no problem. They must only invest some effort to make the Spring OSGi integration still living Best regards Krzysztof On 12.06.2014 22:57, Tim Jones wrote: I am adding a few URLs as I think it is will be of interest to others who are looking for direction re the future of Spring and OSGI -- Somehow I wonder how well future spring versions will behave in OSGi. I think we should start to at least warn our users that continued use of spring in OSGi is an increasing risk. http://karaf.922171.n3.nabble.com/Spring-OSGi-bundles-no-longer-being-released-td4031212.html -- Are we really going to let die the Spring integration with OSGi?http://karaf.922171.n3.nabble.com/Re-The-future-of-the-Spring-with-Fabric8-td4033455.html -- We should also make clear that Spring DM is dead. And that in general Spring on OSGi is not a good ideahttps://github.com/fabric8io/fabric8/issues/1634 -- View this message in context: http://karaf.922171.n3.nabble.com/OSGI-and-Spring-tp4033211p4033485.html Sent from the Karaf - User mailing list archive at Nabble.com. -- Krzysztof Sobkowiak JEE OSS Architect | Technical Architect @ Capgemini Capgemini http://www.pl.capgemini.com/ | Software Solutions Center http://www.pl.capgemini-sdm.com/ | Wroclaw e-mail: krzys.sobkow...@gmail.com | Twitter: @KSobkowiak Calendar: goo.gl/yvsebC -- Charlie Mordant Full OSGI/EE stack made with Karaf: https://github.com/OsgiliathEnterprise/net.osgiliath.parent
Re: OSGI and Spring
Can't you use Aries bean 'factory-ref' and 'init-method' to implement factorybeans? I knew that post processors weren't supported, but never faced the factorybean issue (maybe I didn't dealt with it). 2014-06-13 10:14 GMT+02:00 Guillaume Nodet gno...@apache.org: 2014-06-13 10:02 GMT+02:00 Charlie Mordant cmorda...@gmail.com: As an addition, you can always use Spring beans with Aries-bp, as you would do with any other bp bean. There are two big limitations in Aries that makes reusing spring beans difficult: * FactoryBean are not supported * type based discovery is not supported So for beans that are somewhat tied to any spring api, it's not necessarily an easy task to migrate. The only thing you cannot do without spring-dm/gemini is the use of Spring namespaces/annotations. Namespaces are supported by spring-dm/gemini afaik. I'm pretty sure it's relatively easy to bridge annotation support configuring the right Spring beans: I dropped my devs on it due to my ignorance (5 years ago) on an OSGI-ready Spring classpath scanner implementation. Best regards, 2014-06-12 23:21 GMT+02:00 Krzysztof Sobkowiak krzys.sobkow...@gmail.com : If many people still need a Spring integration with OSGi it should be no problem. ServiceMix Bundles sub-project provides now Spring bundles. We have also Eclipse Gemini Blueprint (successor of Spring DM), but I don't know how active the project is. But usage of Gemini for Spring integration forces usage of the Gemini's Blueprint implementation too. Personally I don't like such a configuration. I prefer usage of Spring DM which, I think so, doesn't need to die. Indeed it's died. But it can be reanimated and provide a lightweight Spring integration -- probably as a new project based on Spring DM code base. If people want (or need) to use Spring in OSGi there should be no problem. They must only invest some effort to make the Spring OSGi integration still living Best regards Krzysztof On 12.06.2014 22:57, Tim Jones wrote: I am adding a few URLs as I think it is will be of interest to others who are looking for direction re the future of Spring and OSGI -- Somehow I wonder how well future spring versions will behave in OSGi. I think we should start to at least warn our users that continued use of spring in OSGi is an increasing risk. http://karaf.922171.n3.nabble.com/Spring-OSGi-bundles-no-longer-being-released-td4031212.html -- Are we really going to let die the Spring integration with OSGi?http://karaf.922171.n3.nabble.com/Re-The-future-of-the-Spring-with-Fabric8-td4033455.html -- We should also make clear that Spring DM is dead. And that in general Spring on OSGi is not a good ideahttps://github.com/fabric8io/fabric8/issues/1634 -- View this message in context: http://karaf.922171.n3.nabble.com/OSGI-and-Spring-tp4033211p4033485.html Sent from the Karaf - User mailing list archive at Nabble.com. -- Krzysztof Sobkowiak JEE OSS Architect | Technical Architect @ Capgemini Capgemini http://www.pl.capgemini.com/ | Software Solutions Center http://www.pl.capgemini-sdm.com/ | Wroclaw e-mail: krzys.sobkow...@gmail.com | Twitter: @KSobkowiak Calendar: goo.gl/yvsebC -- Charlie Mordant Full OSGI/EE stack made with Karaf: https://github.com/OsgiliathEnterprise/net.osgiliath.parent -- Charlie Mordant Full OSGI/EE stack made with Karaf: https://github.com/OsgiliathEnterprise/net.osgiliath.parent
Re: Karaf Custom Distribution with customizations to etc/xxx.cfg files
Hi,
I had the same problem and I solved it by configuring the
maven-resources-plugin to copy the resources into the target/assembly
directory.
Example:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-resources-plugin/artifactId
executions
execution
iddefault-resources/id
phaseprepare-package/phase
goals
goalcopy-resources/goal
/goals
configuration
outputDirectory${basedir}/target/assembly/outputDirectory
resources
resource
directory${basedir}/src/main/filtered-resources/directory
filteringtrue/filtering
includes
include**/*/include
/includes
/resource
/resources
/configuration
/execution
/executions
/plugin
Regards
Jochen
sreeraaman wrote
Is there a provision in the karaf-maven-plugin to achieve this something
similar to the assembly descriptor where under
fileSets/fileSet/excludes/exclude where we can specify the files to
exclude?
--
View this message in context:
http://karaf.922171.n3.nabble.com/Karaf-Custom-Distribution-with-customizations-to-etc-xxx-cfg-files-tp4033048p4033498.html
Sent from the Karaf - User mailing list archive at Nabble.com.
