Re: [osgi-dev] Utility package as a bundle?
The problem with util bundles is that their transitive dependency has a tendency to swell. That would be no problem if the util bundle was cohesive but they rarely are. Example, I once debugged a case where about 20 Mb of external dependencies were dragged in because the developers used one two line method in Apache commons collection. For this reason, bnd has the Conditional-Package instruction. This instruction is ignored while building the bundles but after the content is set, it will match any imports against this instruction. Any matching packages are copied to the bundle which is then reanalyzed until no more matching imported packages are found. For example: Private-Package: biz.aQute.whatever.impl.* Conditional-Package: biz.aQute.util.* Any imports from biz.aQute.util.* will automatically be included in your bundle in your private are. That is, these utils will not be shared. Many bundles can include the same package, one of the great advantages of OSGi over other Java module systems. Obviously this will create redundancy but it gives you less coupling, there is a of course a trade off. However, it is binary redundancy, the source code is still in one location. I find this Conditional-Package to be extremely effective for specially developed util jars. The model works best when the utils themselves are in separate packages, this allows you to pick and choose and not pay for unwanted dependencies. Kind regards, Peter Kriens On 1 dec 2010, at 00:51, Wesley Silva wrote: Hi, I'm currently migrating an existing web application to OSGI. During the process I saw the utility package, where there are classes to manipulate things like date, strings, files, cryptography and so on. Almost all web applications in my company have this kind of package so I was wondering if it was a good idea to turn it into a reused piece of software. So here is my question, is it a good idea to turn it into a bundle? If so, how would this bundle look like? Would it publish some service thought interfaces or just export packages? Any suggestions? -- Att, Wesley MSc Candidate in Software Engineering Specialist in Test Analisys (CIn/UFPE - Motorola) B.S. in Computer science - UFS Sun Certified Java Programmer Sun Certified Web Component Developer ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Bundle Repository Server
To build OBR repositories, I would use tools such as bindex or the maven bundle plugin. You can use the following command line for example: mvn org.apache.felix:maven-bundle-plugin:2.1.0:index -DmavenRepository=~/.m2/repository -DurlTemplate=maven It will generate a repository xml for all your local maven repository. As for the remoting aspect, a given bundle is not really supposed to change imho, but that's a side issue. OBR isn't yet a spec and so only implementation I know about is the one from the Apache Felix project which does not support remoting. Some time ago, I've started a project called RemoteOBR which aimed to be able to have a remote OBR server. See http://gnodet.blogspot.com/2010/09/remoteobr.html for more informations. On Wed, Dec 1, 2010 at 06:44, Martin Ždila m.zd...@mwaysolutions.com wrote: Hello For our application we need update mechanism with dependency handling and with remote repository. Something simmilar like apt-get in Debian or installing new plugins to Eclipse from various repositories or marketplace. From what I've read it looks that the solution could be the Bundle Repository - OBR. Currently all our bundles are stored in the ivy repository together with non-bundle jars used for eg. GWT. BTW We are using our own proprietary build system that integrates ivy, bnd and other libraries, but this is maybe not so important now. To start using OBR we need to generate repository.xml. The best would be if jars would stay in the ivy repository (standard file system accessible over ssh, but there is no problem to add http support) and not duplicate them for the OBR server. Bundles in the repository often changes and so it would be expensive to always regenerate repository.xml for complete repository after every change. We have basically couple questions: 1. how can we generate OBR repository.xml for every bundle? The source for generation could be MANIFEST.MF and DS component.xmls. 2. is there any OBR server that can dynamically aggregate OBR xml of every bundle to repository.xml? It must be dynamic, because bundles often changes. 3. is there some solutions to combine it with ivy.xml descriptions? In next step we would maybe like to also update our building system to use metadata from OBR to handle compile-time dependencies. We may consider Sigil. But not all jars are bundles - many jars are GWT jars and jars for other purposes. But we'll have more questions about this once we have our OBR server running :-) Thanks in advance -- Ing. Martin Ždila CTO M-Way Solutions Slovakia s.r.o. Letná 27, 040 01 Košice Slovakia tel:+421-908-363-848 mailto:m.zd...@mwaysolutions.com http://www.mwaysolutions.com ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Bundle Repository Server
On 1 December 2010 12:27, Guillaume Nodet gno...@gmail.com wrote: To build OBR repositories, I would use tools such as bindex or the maven bundle plugin. You can use the following command line for example: mvn org.apache.felix:maven-bundle-plugin:2.1.0:index -DmavenRepository=~/.m2/repository -DurlTemplate=maven It will generate a repository xml for all your local maven repository. Nice feature. I was looking for this a few weeks ago, but couldn't see it documented on the maven-bundle-plugin site even though I could see that it uses Bindex inside. I guess I should have done a mvn help:describe on the maven-bundle-plugin which does indeed list bundle:index as a goal. Would still be nice to have this described in the plugin web site though ;-) Cheers, Jeremy ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Utility package as a bundle?
A smarter bundle tool should be able to eliminate unused utility classes from such bundles, greatly reducing their size. But making bundles more fine grained is definitely a good tip too. Greetings, Marcel On 1 Dec 2010, at 15:58 , Simon J Archer wrote: I have had a similar experience with utility bundles. Be sure to carefully manage the prerequisites of a commonly used bundle. The trouble, as Jeff correctly pointed out, is that they become dumping grounds for useful types, and as a result their prerequisites (that is, the other bundles upon which they depend) tend to grow. While having a large number of prerequisites is not in itself a bad thing, it has a negative impact on all those bundles higher on the stack that just want to use one or two types in the utility bundle. In my case I saw a small 2 MB application balloon to over 20 MB just because someone updated one of the packages I imported, and consequently the bundle's prerequisites. So, what's the solution? Ensure that your utility bundle remains highly cohesive and does not become a grab-bag of unrelated helpers. Far better to create multiple finely-grained, highly cohesive (and loosely coupled!) bundles since this will result in a far more flexible bundle dependency graph, be it at the cost of some complexity. I've seen first hand the reaction people have to finely grained bundles, and I've seen people merge bundles to make things easier. The reality is that when you merge bundles you are trading flexibility for simplicity (less bundles). One day I'll write a packaging tool that merges bundles for deployment, giving us the best of both worlds. To that end, I would like to suggest using Import-Package rather than Require-Bundle, since this gives you more flexibility regarding you prerequisites. But let's save that debate for other thread. Simon From: Peter Kriens peter.kri...@aqute.biz To: OSGi Developer Mail List osgi-dev@mail.osgi.org Date: 12/01/2010 04:00 AM Subject: Re: [osgi-dev] Utility package as a bundle? Sent by: osgi-dev-boun...@mail.osgi.org The problem with util bundles is that their transitive dependency has a tendency to swell. That would be no problem if the util bundle was cohesive but they rarely are. Example, I once debugged a case where about 20 Mb of external dependencies were dragged in because the developers used one two line method in Apache commons collection. For this reason, bnd has the Conditional-Package instruction. This instruction is ignored while building the bundles but after the content is set, it will match any imports against this instruction. Any matching packages are copied to the bundle which is then reanalyzed until no more matching imported packages are found. For example: Private-Package: biz.aQute.whatever.impl.* Conditional-Package: biz.aQute.util.* Any imports from biz.aQute.util.* will automatically be included in your bundle in your private are. That is, these utils will not be shared. Many bundles can include the same package, one of the great advantages of OSGi over other Java module systems. Obviously this will create redundancy but it gives you less coupling, there is a of course a trade off. However, it is binary redundancy, the source code is still in one location. I find this Conditional-Package to be extremely effective for specially developed util jars. The model works best when the utils themselves are in separate packages, this allows you to pick and choose and not pay for unwanted dependencies. Kind regards, Peter Kriens On 1 dec 2010, at 00:51, Wesley Silva wrote: Hi, I'm currently migrating an existing web application to OSGI. During the process I saw the utility package, where there are classes to manipulate things like date, strings, files, cryptography and so on. Almost all web applications in my company have this kind of package so I was wondering if it was a good idea to turn it into a reused piece of software. So here is my question, is it a good idea to turn it into a bundle? If so, how would this bundle look like? Would it publish some service thought interfaces or just export packages? Any suggestions? -- Att, Wesley MSc Candidate in Software Engineering Specialist in Test Analisys (CIn/UFPE - Motorola) B.S. in Computer science - UFS Sun Certified Java Programmer Sun Certified Web Component Developer ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org
Re: [osgi-dev] Utility package as a bundle?
It may be the only way but I have to say I'd be concerned about maintenance if we ended up shipping 100 copies of the same util classes. Historically in Eclipse we have had a number of widely used utility classes that had subtle/complex behaviour (e.g., StringMatcher, Path, ...). The sort of thing that you think should be easy but turn out to be hard. Inevitably bugs crop up or tweaks are done. If every user of those classes had their own copy, deploying changes would be a nightmare. In the end there is a balance in there somewhere. Jeff On 2010-12-01, at 10:16 AM, Marcel Offermans wrote: A smarter bundle tool should be able to eliminate unused utility classes from such bundles, greatly reducing their size. But making bundles more fine grained is definitely a good tip too. Greetings, Marcel On 1 Dec 2010, at 15:58 , Simon J Archer wrote: I have had a similar experience with utility bundles. Be sure to carefully manage the prerequisites of a commonly used bundle. The trouble, as Jeff correctly pointed out, is that they become dumping grounds for useful types, and as a result their prerequisites (that is, the other bundles upon which they depend) tend to grow. While having a large number of prerequisites is not in itself a bad thing, it has a negative impact on all those bundles higher on the stack that just want to use one or two types in the utility bundle. In my case I saw a small 2 MB application balloon to over 20 MB just because someone updated one of the packages I imported, and consequently the bundle's prerequisites. So, what's the solution? Ensure that your utility bundle remains highly cohesive and does not become a grab-bag of unrelated helpers. Far better to create multiple finely-grained, highly cohesive (and loosely coupled!) bundles since this will result in a far more flexible bundle dependency graph, be it at the cost of some complexity. I've seen first hand the reaction people have to finely grained bundles, and I've seen people merge bundles to make things easier. The reality is that when you merge bundles you are trading flexibility for simplicity (less bundles). One day I'll write a packaging tool that merges bundles for deployment, giving us the best of both worlds. To that end, I would like to suggest using Import-Package rather than Require-Bundle, since this gives you more flexibility regarding you prerequisites. But let's save that debate for other thread. Simon From:Peter Kriens peter.kri...@aqute.biz To: OSGi Developer Mail List osgi-dev@mail.osgi.org Date:12/01/2010 04:00 AM Subject: Re: [osgi-dev] Utility package as a bundle? Sent by: osgi-dev-boun...@mail.osgi.org The problem with util bundles is that their transitive dependency has a tendency to swell. That would be no problem if the util bundle was cohesive but they rarely are. Example, I once debugged a case where about 20 Mb of external dependencies were dragged in because the developers used one two line method in Apache commons collection. For this reason, bnd has the Conditional-Package instruction. This instruction is ignored while building the bundles but after the content is set, it will match any imports against this instruction. Any matching packages are copied to the bundle which is then reanalyzed until no more matching imported packages are found. For example: Private-Package: biz.aQute.whatever.impl.* Conditional-Package: biz.aQute.util.* Any imports from biz.aQute.util.* will automatically be included in your bundle in your private are. That is, these utils will not be shared. Many bundles can include the same package, one of the great advantages of OSGi over other Java module systems. Obviously this will create redundancy but it gives you less coupling, there is a of course a trade off. However, it is binary redundancy, the source code is still in one location. I find this Conditional-Package to be extremely effective for specially developed util jars. The model works best when the utils themselves are in separate packages, this allows you to pick and choose and not pay for unwanted dependencies. Kind regards, Peter Kriens On 1 dec 2010, at 00:51, Wesley Silva wrote: Hi, I'm currently migrating an existing web application to OSGI. During the process I saw the utility package, where there are classes to manipulate things like date, strings, files, cryptography and so on. Almost all web applications in my company have this kind of package so I was wondering if it was a good idea to turn it into a reused piece of software. So here is my question, is it a good idea to turn it into a bundle? If so, how would this bundle look like? Would it publish some service thought interfaces or just export packages? Any suggestions? --
Re: [osgi-dev] Utility package as a bundle?
One further cautionary note: watch the uses constraints on the packages you export. bnd in particular has to be conservative about what it includes, so you may find it necessary to deal with the constraints manually. Otherwise, one Import-Package can tie your bundle to many other things that may not strictly be necessary. I'm chopping up my own big-hunk o' utils at the moment On 11/30/2010 08:02 PM, Jeff McAffer wrote: What Richard said plus a cautionary note. These sorts of common or util bundles have a way of growing and taking on a life of their own. People have a tendency to use them as dumping grounds for that little class that everyone will want etc. To help mitigate this tendency: - clearly define the scope of what goes in the bundle and what does not - maintain high coherence in your package namespace (don't just put all the things in a utils package) - encourage people to use Import-Package to enable shipping various shapes of util bundle From an organizational point of view, you likely want to also establish what group/team/person is responsible for the content of the bundle(s). Topics like content regulation, maintenance, ... Jeff On 2010-11-30, at 7:32 PM, Richard S. Hall wrote: A simple library bundle would likely just export the packages it wishes to share. Not all bundles need to provide services. Services decouple bundles from implementation details, enabling multiple providers and dynamism. Package sharing is another valid form of bundle collaboration, it is just a little less flexible. That doesn't mean it should be avoided completely, nor can it. Now if you thought you might have multiple implementations of these utilities that you wanted to swap out dynamically, then defining services might make sense. But even at the package level you can have multiple implementations, it only means that swapping out implementations is slightly more traumatic on your system. - richard On 11/30/10 6:51 PM, Wesley Silva wrote: Hi, I'm currently migrating an existing web application to OSGI. During the process I saw the utility package, where there are classes to manipulate things like date, strings, files, cryptography and so on. Almost all web applications in my company have this kind of package so I was wondering if it was a good idea to turn it into a reused piece of software. So here is my question, is it a good idea to turn it into a bundle? If so, how would this bundle look like? Would it publish some service thought interfaces or just export packages? Any suggestions? -- Tommy M. McGuire mcgu...@crsr.net ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Utility package as a bundle?
Well, there can obviously be a difference between the deployment view for a project, where you have only a single copy of such utility classes (in other words, I'm totally against making copies of the source code here) and how to package the sources into bundles, the deployment view. So with only one source copy, which gets compiled and included into each bundle that uses it I feel you get the best of both worlds: no duplication of source code and no coupling at deployment time. But I totally agree, there is a balance here, and there is no generic answer. :) Greetings, Marcel On 1 Dec 2010, at 16:23 , Jeff McAffer wrote: It may be the only way but I have to say I'd be concerned about maintenance if we ended up shipping 100 copies of the same util classes. Historically in Eclipse we have had a number of widely used utility classes that had subtle/complex behaviour (e.g., StringMatcher, Path, ...). The sort of thing that you think should be easy but turn out to be hard. Inevitably bugs crop up or tweaks are done. If every user of those classes had their own copy, deploying changes would be a nightmare. In the end there is a balance in there somewhere. Jeff On 2010-12-01, at 10:16 AM, Marcel Offermans wrote: A smarter bundle tool should be able to eliminate unused utility classes from such bundles, greatly reducing their size. But making bundles more fine grained is definitely a good tip too. Greetings, Marcel On 1 Dec 2010, at 15:58 , Simon J Archer wrote: I have had a similar experience with utility bundles. Be sure to carefully manage the prerequisites of a commonly used bundle. The trouble, as Jeff correctly pointed out, is that they become dumping grounds for useful types, and as a result their prerequisites (that is, the other bundles upon which they depend) tend to grow. While having a large number of prerequisites is not in itself a bad thing, it has a negative impact on all those bundles higher on the stack that just want to use one or two types in the utility bundle. In my case I saw a small 2 MB application balloon to over 20 MB just because someone updated one of the packages I imported, and consequently the bundle's prerequisites. So, what's the solution? Ensure that your utility bundle remains highly cohesive and does not become a grab-bag of unrelated helpers. Far better to create multiple finely-grained, highly cohesive (and loosely coupled!) bundles since this will result in a far more flexible bundle dependency graph, be it at the cost of some complexity. I've seen first hand the reaction people have to finely grained bundles, and I've seen people merge bundles to make things easier. The reality is that when you merge bundles you are trading flexibility for simplicity (less bundles). One day I'll write a packaging tool that merges bundles for deployment, giving us the best of both worlds. To that end, I would like to suggest using Import-Package rather than Require-Bundle, since this gives you more flexibility regarding you prerequisites. But let's save that debate for other thread. Simon From: Peter Kriens peter.kri...@aqute.biz To: OSGi Developer Mail List osgi-dev@mail.osgi.org Date: 12/01/2010 04:00 AM Subject:Re: [osgi-dev] Utility package as a bundle? Sent by:osgi-dev-boun...@mail.osgi.org The problem with util bundles is that their transitive dependency has a tendency to swell. That would be no problem if the util bundle was cohesive but they rarely are. Example, I once debugged a case where about 20 Mb of external dependencies were dragged in because the developers used one two line method in Apache commons collection. For this reason, bnd has the Conditional-Package instruction. This instruction is ignored while building the bundles but after the content is set, it will match any imports against this instruction. Any matching packages are copied to the bundle which is then reanalyzed until no more matching imported packages are found. For example: Private-Package: biz.aQute.whatever.impl.* Conditional-Package: biz.aQute.util.* Any imports from biz.aQute.util.* will automatically be included in your bundle in your private are. That is, these utils will not be shared. Many bundles can include the same package, one of the great advantages of OSGi over other Java module systems. Obviously this will create redundancy but it gives you less coupling, there is a of course a trade off. However, it is binary redundancy, the source code is still in one location. I find this Conditional-Package to be extremely effective for specially developed util jars. The model works best when the utils themselves are in separate packages, this allows you to pick and choose and not pay for unwanted dependencies. Kind regards, Peter Kriens
Re: [osgi-dev] Utility package as a bundle?
On 2010-12-01, at 3:26 PM, Marcel Offermans wrote: Well, there can obviously be a difference between the deployment view for a project, where you have only a single copy of such utility classes (in other words, I'm totally against making copies of the source code here) and how to package the sources into bundles, the deployment view. So with only one source copy, which gets compiled and included into each bundle that uses it I feel you get the best of both worlds: no duplication of source code and no coupling at deployment time. Right I was assuming no source duplication (that would be a nightmare!). Even so, we likely have dozens if not a hundred bundles that use some of these utility classes. In many cases there is no build that does them all and they are on different release cycles and ... So actually propagating changes is a challenge as it means rebuilding and redeploying all the bundles not just one. But I totally agree, there is a balance here, and there is no generic answer. :) Absolutely. The topics I mentioned are things to watch for not nails in the coffin. Jeff ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
