Re: [osgi-dev] Put API/SPI/implementation into separate bundles?
On Wed, Sep 24, 2008 at 17:53, Stuart McCulloch [EMAIL PROTECTED] wrote: 2008/9/24 Yvan Royon [EMAIL PROTECTED] The way I see it, an OSGi bundle tries to fit both granularities at the same time. Thus, it is up to the packager to choose one or the other, or a little of both, and it can be ugly. In my opinion, OSGi (or maybe just OBR and the shell service) needs a way to express group-of-bundles-that-go-together-to-form-a-useful-app, so that developers and packagers can express both granularities. perhaps something like this :) http://www.osgi.org/javadoc/r4/org/osgi/service/deploymentadmin/DeploymentPackage.html although there's still plenty of scope for further development / tooling... Ah, so I should have paid attention to those hundreds of pages after all :) Well, it's a little disappointing that DeploymentPackages (and p2 Installable Units, from what I gather) are not first-class OSGi citizens. What is kind of a breaker is this: Two deployment packages are not allowed to create or manipulate the same artifact. This means in an open platform, with multiple software providers, I can't wrap a whole hypothetical application in a single DeploymentPackage if it includes standard or widely-used services. I need to carefully identify and separate some parts of the application from the no-longer-global package, if I want to play nice with others. And then use an extension such as OBR to ease the deployment of those remaining parts. That's a bit of useless complexity, and 2 layers of optional features, for something quite basic (single-click application deployment, on a deployment platform...). I sound trollish, but oh well :) -- Yvan Royon ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Put API/SPI/implementation into separate bundles?
Sorry to bump a 4 month old thread... On Mon, Jun 9, 2008 at 09:18, Peter Kriens [EMAIL PROTECTED] wrote: The whole problem with modularity is the -granularity-. If you make the granularity too small you end up with too many artifacts to comprehend. If you make it too large you do not get the desired mix and match behavior. Compare this with recursive component models, say, Fractal. Maybe SCA fits the bill also. With these systems you have composite components and unit components. A unit components contains actual code (impl, api, whatever). It can be as small as the developers' smallest unit of reuse. A composite component embeds unit components and/or other composite components. It allows you to package and distribute your code: the whole app is a composite, then inside are composites that relate to different parts in the design of your application, then ... etc. You ony need a single component to deploy the whole application, whether it is a SimpleHttpClient or the whole HugeAndComplex IDE. It is thus much simpler for an end-user or admin to browse a catalogue and to choose an application to deploy. The way I see it, an OSGi bundle tries to fit both granularities at the same time. Thus, it is up to the packager to choose one or the other, or a little of both, and it can be ugly. In my opinion, OSGi (or maybe just OBR and the shell service) needs a way to express group-of-bundles-that-go-together-to-form-a-useful-app, so that developers and packagers can express both granularities. -- Yvan Royon ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Put API/SPI/implementation into separate bundles?
2008/9/24 Yvan Royon [EMAIL PROTECTED] Sorry to bump a 4 month old thread... On Mon, Jun 9, 2008 at 09:18, Peter Kriens [EMAIL PROTECTED] wrote: The whole problem with modularity is the -granularity-. If you make the granularity too small you end up with too many artifacts to comprehend. If you make it too large you do not get the desired mix and match behavior. Compare this with recursive component models, say, Fractal. Maybe SCA fits the bill also. With these systems you have composite components and unit components. A unit components contains actual code (impl, api, whatever). It can be as small as the developers' smallest unit of reuse. A composite component embeds unit components and/or other composite components. It allows you to package and distribute your code: the whole app is a composite, then inside are composites that relate to different parts in the design of your application, then ... etc. You ony need a single component to deploy the whole application, whether it is a SimpleHttpClient or the whole HugeAndComplex IDE. It is thus much simpler for an end-user or admin to browse a catalogue and to choose an application to deploy. The way I see it, an OSGi bundle tries to fit both granularities at the same time. Thus, it is up to the packager to choose one or the other, or a little of both, and it can be ugly. In my opinion, OSGi (or maybe just OBR and the shell service) needs a way to express group-of-bundles-that-go-together-to-form-a-useful-app, so that developers and packagers can express both granularities. perhaps something like this :) http://www.osgi.org/javadoc/r4/org/osgi/service/deploymentadmin/DeploymentPackage.html although there's still plenty of scope for further development / tooling... -- Yvan Royon ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev -- Cheers, Stuart ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Put API/SPI/implementation into separate bundles?
Or even something like Equinox's p2 support. It allows you to publish bundles and collections of bundles and manage dependencies on arbitrary capabilities and requirements. To a certain degree you can do similar things with OBR it is just harder to create the metadata and the capability namespace is not (AFAIK) extensible. See http://wiki.eclipse.org/Equinox/p2 Jeff Stuart McCulloch wrote: 2008/9/24 Yvan Royon [EMAIL PROTECTED] Sorry to bump a 4 month old thread... On Mon, Jun 9, 2008 at 09:18, Peter Kriens [EMAIL PROTECTED] wrote: The whole problem with modularity is the -granularity-. If you make the granularity too small you end up with too many artifacts to comprehend. If you make it too large you do not get the desired mix and match behavior. Compare this with recursive component models, say, Fractal. Maybe SCA fits the bill also. With these systems you have composite components and unit components. A unit components contains actual code (impl, api, whatever). It can be as small as the developers' smallest unit of reuse. A composite component embeds unit components and/or other composite components. It allows you to package and distribute your code: the whole app is a composite, then inside are composites that relate to different parts in the design of your application, then ... etc. You ony need a single component to deploy the whole application, whether it is a SimpleHttpClient or the whole HugeAndComplex IDE. It is thus much simpler for an end-user or admin to browse a catalogue and to choose an application to deploy. The way I see it, an OSGi bundle tries to fit both granularities at the same time. Thus, it is up to the packager to choose one or the other, or a little of both, and it can be ugly. In my opinion, OSGi (or maybe just OBR and the shell service) needs a way to express "group-of-bundles-that-go-together-to-form-a-useful-app", so that developers and packagers can express both granularities. perhaps something like this :) http://www.osgi.org/javadoc/r4/org/osgi/service/deploymentadmin/DeploymentPackage.html although there's still plenty of scope for further development / tooling... -- Yvan Royon ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev -- Cheers, Stuart ___ 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] Put API/SPI/implementation into separate bundles?
This is certainly an option if you are the author of both the client and impl but for cases where there is a third party library with an api you want to use it seems a little odd to include the third party lib in all the client bundles? Definitely more than one way to solve this which is great. Also assuming you use import-package and not require-bundle (shudder at prospect) you can always refactor your application from a single bundle to multiple bundles (or in the other direction) when/if you find the problem. I guess from a distributed point of view I tend to start from one end of the problem where as embedded development tends to start at the other end and all depends on which ever model you find easiest to work with. Regards, Dave Peter Kriens wrote: In that case, you include the API in the client. In R4 it became a bit more complex because there can now be multiple class spaces. In R4, I always added the API to the client. Kind regards, Peter Kriens On 2 jun 2008, at 23:46, Mirko Jahn wrote: Concerning this... Huh? If only com.bar is present than these dependencies exist anyway? A: Import-Package: com.foo B: Export-Package: com.foo Import-Package: com.bar, com.baz A will resolve to B. B has dependencies that are required to implement com.foo. If I take implementation C: C: Export-Package: com.foo Import-Package: com.bzz I will get different dependencies, but A remains oblivious of all this. Agreed, but the problem David was talking about is a different one (I guess). What if you don't actually need the implementation right away. In a very dynamic and as small as possible environment, you just want to have an API and load the implementation later on an as needed basis. Now, if you always distribute the implementation all the dependencies of the Implementation (and their dependencies and so on) have to be present in the container and need to be resolved. Of course you can just define your implementation optional in this case and the question, if you should depend on the API in a fixed instead of an optional way remains, but I think this was the use case David was talking about. One example I can think of out of the top of my head is logging. You might want to have the API present, but no logging service deployed, because it is some sort of thin (ultra light) client. If the service is there, use it, if not... don't bother. Just for the sack of arguments, you can also provide a /dev/null logger as the default implementation, which wouldn't have any dependencies. I think there is plenty of space to argue here. Ultimately, there is no black or white only different shades of gray ;-) Just my 2 cents... Cheers, Mirko ___ 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 ___ This email has been scanned by both Message Labs and Paremus internal systems for viruses and inappropriate attachments. Email suspected of carrying a virus payload or inappropriate attachment will not be delivered to you, and the sender will receive an appropriate warning notice. ___ ___ Paremus Limited. Registered in England No. 4181472 Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA Postal Address: 107-111 Fleet Street, London, EC4A 2AB The information transmitted is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ___ ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Put API/SPI/implementation into separate bundles?
To expand on this train of thought as it's getting on towards of end of day here in the UK so I feel the urge to talk to the wall ;) The consideration when building bundles is how best to weight the distribution of code between bundles is which code belongs together from a client perspective. As with all API decision the designer needs to put themselves in the clients shoes to decide the correct grouping of classes. From my view point I try to ensure where ever possible that API bundles should be dependent only on other API bundles. This limits the possible spread of the graph beyond the classes need to express the core semantics of the API. The pain comes when trying to start client code that depends on an api and you end up in the cyclical process of resolving the next bundle required to start. In newton where we're dealing with remote deployment of bundles this also has a performance aspect as client code should not depend on downloading server implementations in order to function. Possible analogies can be made with physical phenomena such as center of mass and entanglement. You don't want to have to drag down the weight of an entire planet just to switch a light switch etc. So in summary my advice would be to separate impl and api but do so in such a way as to inherit apis and group related apis for semantic coherency - simple :) Regards, Dave (shameless link to newton) http://newton.codecauldron.org David Savage wrote: Jeff McAffer wrote: Leaping on this thread as it's something I've had a lot of experience unpicking and wouldn't want others to have same pain. Another issue that is worth considering (and yet another reason to separate into api and impl) is that due to osgi resolution requirements if you put your impl in the same bundle as the api this effectively requires client code to resolve bundles that your impl uses but they may have no need of using. This can rapidly get out of control and in the worst case a client needs to import a much larger set of bundles to use a client api than would otherwise be needed. Yes, this is definitely a concern. Just to paint the flip side of the spectrum, if you put the API in a separate bundle then either you have a lot of small bundles (high overhead ratio in management and runtime foot print) or you lump together unrelated API and have a similar problem to what you describe. I'm not countering but rather suggesting that there is not a single, one size fits all answer. Agreed on all points. Regards, Dave. Jeff ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ This email has been scanned by both Message Labs and Paremus internal systems for viruses and inappropriate attachments. Email suspected of carrying a virus payload or inappropriate attachment will not be delivered to you, and the sender will receive an appropriate warning notice. ___ ___ Paremus Limited. Registered in England No. 4181472 Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA Postal Address: 107-111 Fleet Street, London, EC4A 2AB The information transmitted is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ___ ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Put API/SPI/implementation into separate bundles?
Hmm. I like implementations that carry their interfaces. OSGi can handle multiple implementations that carry the same API code. Refreshing might then sometimes restart a bundle that could have been prevented but I fail to see that as a big drawback. I think it is crucial that bundles run out of the box and not require you to chase other bundles to get it to work. This first level experience is quite important. Just doubling the number of bundles because you might have to stop a bundle does not like the right trade off to me. In the OSGi build, all the implementations care the interfaces they implement so they always run out of the box so setup is simplified. I.e., the org.osgi.impl.service.log .jar bundle carries the packages org.osgi.impl.service.log + org.osgi.service.log. Obviously, bnd makes it quite simple to construct these type of bundles. Kind regards, Peter Kriens On 2 jun 2008, at 18:11, Jeff McAffer wrote: Leaping on this thread as it's something I've had a lot of experience unpicking and wouldn't want others to have same pain. Another issue that is worth considering (and yet another reason to separate into api and impl) is that due to osgi resolution requirements if you put your impl in the same bundle as the api this effectively requires client code to resolve bundles that your impl uses but they may have no need of using. This can rapidly get out of control and in the worst case a client needs to import a much larger set of bundles to use a client api than would otherwise be needed. Yes, this is definitely a concern. Just to paint the flip side of the spectrum, if you put the API in a separate bundle then either you have a lot of small bundles (high overhead ratio in management and runtime foot print) or you lump together unrelated API and have a similar problem to what you describe. I'm not countering but rather suggesting that there is not a single, one size fits all answer. Jeff ___ 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] Put API/SPI/implementation into separate bundles?
Concerning this... Huh? If only com.bar is present than these dependencies exist anyway? A: Import-Package: com.foo B: Export-Package: com.foo Import-Package: com.bar, com.baz A will resolve to B. B has dependencies that are required to implement com.foo. If I take implementation C: C: Export-Package: com.foo Import-Package: com.bzz I will get different dependencies, but A remains oblivious of all this. Agreed, but the problem David was talking about is a different one (I guess). What if you don't actually need the implementation right away. In a very dynamic and as small as possible environment, you just want to have an API and load the implementation later on an as needed basis. Now, if you always distribute the implementation all the dependencies of the Implementation (and their dependencies and so on) have to be present in the container and need to be resolved. Of course you can just define your implementation optional in this case and the question, if you should depend on the API in a fixed instead of an optional way remains, but I think this was the use case David was talking about. One example I can think of out of the top of my head is logging. You might want to have the API present, but no logging service deployed, because it is some sort of thin (ultra light) client. If the service is there, use it, if not... don't bother. Just for the sack of arguments, you can also provide a /dev/null logger as the default implementation, which wouldn't have any dependencies. I think there is plenty of space to argue here. Ultimately, there is no black or white only different shades of gray ;-) Just my 2 cents... Cheers, Mirko ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
