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?
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?
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?
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?
Peter, you live in a different world... Yes, one where I still think exploding things is the wrong way to go ... :-( Yes, I do think there would not be a serious problem if several parts of Eclipse was delivered as one bundle; there is no value in modularity itself. A bundle/module should reduce the overall complexity by minimizing the coupling, if two bundles can only live together they are the same module, just distributed as two parts. Obviously, Eclipse has many plugins that are highly cohesive and have a minimal interface towards the outside world so I would never propose to go back to the monolithic approach. Taking a statement and extrapolating it to its extreme is rarely very useful. 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. You seem to want simple approaches where we get a recipe what to do, and then black and white is easy, but usual very wrong. The truth is usual somewhere in the middle and gray. Kind regards, Peter Kriens On 5 jun 2008, at 16:59, Niclas Hedhman wrote: On Wednesday 04 June 2008 14:27, Peter Kriens wrote: I often see bundles that can only live when some other bundles are around as well, tightly coupled. Why not put these bundles in one bundle? Yes, why not create a single bundle with all my code (let's say Eclipse) in it. Then I can throw away OSGi altogether and simply use the common public-static-void-main container ;o) Peter, you live in a different world... Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug ___ 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?
On 5 jun 2008, at 16:55, Niclas Hedhman wrote: Scenario; 600 bundles, all use Log Service, Log Service implementation needs an upgrade. 600 bundles stopped, 20 minute startup time (we got terrible bundle developers ;o) , instead of a sub-second reload of the LogService Impl bundle ( well, and a few thousand ServiceTrackers working overtime ;o) ) With these things there is only one answer: show me. Try to create a real system that shows this behavior and where updating this "used by all" bundle becomes a real bottleneck. It is easy to dream up horror scenarios but in reality you do not update the log service bundle many times a day, if ever. I suspect the more a bundle is used, the less frequent its updates are because it needs to be stable. But I would have to measure that to know that with more certainty. If the version of the LogService is updated, you're still screwed :-( Anyway, if you have bad bundle developers, who cares? Then you have lots of other problems as well, then this seems to be the least of your worries. :-) IMHO, the lower down the application stack you are, the greater the benefit to separate API from Impl. And for large applications, it doesn't matter if I need 200 or 400 bundles for it to run, I still need a good Bundle Management system in place. Yeah, lets make a big mess so we can sell tools to solve the mess ... :-) This is a multiplier effect I think we allow too often. Though I do agree with a good bundle management system, I do not think that should become an excuse to multiply the number of bundles. Anyway, the trick is, as several people have said, to understand your use case and make your own trade offs. Just want to make sure that this is not a black and white world and there are trade offs. Kind regards, Peter Kriens Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug ___ 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?
On Tuesday 03 June 2008 02:59, Peter Kriens wrote: > 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. I think this is an example of "Terrible Use of packaging API with Implementation". Scenario; 600 bundles, all use Log Service, Log Service implementation needs an upgrade. 600 bundles stopped, 20 minute startup time (we got terrible bundle developers ;o) , instead of a sub-second reload of the LogService Impl bundle ( well, and a few thousand ServiceTrackers working overtime ;o) ) IMHO, the lower down the application stack you are, the greater the benefit to separate API from Impl. And for large applications, it doesn't matter if I need 200 or 400 bundles for it to run, I still need a good Bundle Management system in place. Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug ___ 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?
On Wednesday 04 June 2008 14:27, Peter Kriens wrote: > I often see bundles that can only live when some other bundles are > around as well, tightly coupled. Why not put these bundles in one > bundle? Yes, why not create a single bundle with all my code (let's say Eclipse) in it. Then I can throw away OSGi altogether and simply use the common public-static-void-main container ;o) Peter, you live in a different world... Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug ___ 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?
Perhaps we are not talking about the same thing. If you follow what I think you are saying, you would end up with one bundle for the whole system. Clearly bundles use other services so for a bundle to work, bundles supplying the other services need to be installed. That is a harder problem to manage/address (dependencies are less well specified) than saying that you need an API bundle as well. Anyway, I think we are all in violent agreement that best practices around bundling of packages is contextual. The only differences appearing stem from our varied backgrounds and contexts. Jeff > -Original Message- > From: [EMAIL PROTECTED] [mailto:osgi-dev- > [EMAIL PROTECTED] On Behalf Of Peter Kriens > Sent: Wednesday, June 04, 2008 2:28 AM > To: OSGi Developer Mail List > Subject: Re: [osgi-dev] Put API/SPI/implementation into separate > bundles? > > Well, maybe part of the problem is that bundles are not self contained? > > I often see bundles that can only live when some other bundles are > around as well, tightly coupled. Why not put these bundles in one > bundle? > > I do believe repositories are necessary, but I am also a strong > believer of doing > it right from the beginning and not using the tools to solve problems > that were > created earlier. The tools already have a hard enough time with the > intrinsic > complexity. > > Kind regards, > > Peter Kriens > > On 3 jun 2008, at 14:15, Jeff McAffer wrote: > > >> 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. > > > > It is important to simplify consumption. Agreed. However, > > personally I > > don't find this to be a motivating argument here. In our experience > > writing > > large OSGi-based systems it is relatively rare that a bundle > > implementation > > is self-contained so putting the API with the impl still does not > > give you > > just one bundle you can install and run. > > > > Instead I would prefer to see people use a comprehensive provisioning > > mechanism (insert shameless plug for p2) rather than sacrifice > > architecture > > or flexibility. This is not to say that putting API with impl is > > wrong, > > just that the "out of the box" argument does not work for me. > > > > 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 ___ 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?
Well, maybe part of the problem is that bundles are not self contained? I often see bundles that can only live when some other bundles are around as well, tightly coupled. Why not put these bundles in one bundle? I do believe repositories are necessary, but I am also a strong believer of doing it right from the beginning and not using the tools to solve problems that were created earlier. The tools already have a hard enough time with the intrinsic complexity. Kind regards, Peter Kriens On 3 jun 2008, at 14:15, Jeff McAffer wrote: 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. It is important to simplify consumption. Agreed. However, personally I don't find this to be a motivating argument here. In our experience writing large OSGi-based systems it is relatively rare that a bundle implementation is self-contained so putting the API with the impl still does not give you just one bundle you can install and run. Instead I would prefer to see people use a comprehensive provisioning mechanism (insert shameless plug for p2) rather than sacrifice architecture or flexibility. This is not to say that putting API with impl is wrong, just that the "out of the box" argument does not work for me. 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?
Jeff McAffer wrote: 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. It is important to simplify consumption. Agreed. However, personally I don't find this to be a motivating argument here. In our experience writing large OSGi-based systems it is relatively rare that a bundle implementation is self-contained so putting the API with the impl still does not give you just one bundle you can install and run. Instead I would prefer to see people use a comprehensive provisioning mechanism (insert shameless plug for p2) chuckle :) rather than sacrifice architecture or flexibility. This is not to say that putting API with impl is wrong, just that the "out of the box" argument does not work for me. I think there's another issue that even a comprehensive provisioning mechanism (also like that used in newton ;) ) can't solve and that's when the export-uses graph gets so tangled that it's impossible to resolve all bundles in the jvm at the same time. Thankfully this problem raises its head /very/ infrequently - I've never found it yet in any practical situation but always worth knowing about the beasties that can be found out in the deep ocean. If each developer /tries/ to limit the amount of graph they couple their client code to it helps reduce the risk of getting to tangled up in the reafs just out side of port. (Must be the end of the day again, I'm rambling) 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?
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?
As a supplier of an OSGi platform we have since long come to the conclusion not to take a stand in this question, and instead let the user decide which model to use. In Knopflerfish we supply every OSGi service is three different packages: _api => API part only _impl => impl. only, no API _all => both API and impl. Which model works best is very dependent on what kind of system you are building with the OSGi technology. One small difference we have found in applying the two methods is between in-house closed system, compared to a system in which you install 3rd party bundles, sometimes done by an end user. In the latter case self-contained bundles can sometimes be preferred to reduce dependencies and complexity. On the other hand with a top-class provisioning system you shouldn't have to worry ;-) Regards, Christer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff McAffer Sent: den 3 juni 2008 14:16 To: 'OSGi Developer Mail List' Subject: RE: [osgi-dev] Put API/SPI/implementation into separate bundles? > 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. It is important to simplify consumption. Agreed. However, personally I don't find this to be a motivating argument here. In our experience writing large OSGi-based systems it is relatively rare that a bundle implementation is self-contained so putting the API with the impl still does not give you just one bundle you can install and run. Instead I would prefer to see people use a comprehensive provisioning mechanism (insert shameless plug for p2) rather than sacrifice architecture or flexibility. This is not to say that putting API with impl is wrong, just that the "out of the box" argument does not work for me. 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?
> 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. It is important to simplify consumption. Agreed. However, personally I don't find this to be a motivating argument here. In our experience writing large OSGi-based systems it is relatively rare that a bundle implementation is self-contained so putting the API with the impl still does not give you just one bundle you can install and run. Instead I would prefer to see people use a comprehensive provisioning mechanism (insert shameless plug for p2) rather than sacrifice architecture or flexibility. This is not to say that putting API with impl is wrong, just that the "out of the box" argument does not work for me. Jeff ___ 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?
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
Re: [osgi-dev] Put API/SPI/implementation into separate bundles?
Hi Peter, Totally agreed with your point - if the bundle is self-contained - i.e. the implementation does not depend on importing packages from other bundles. This is a good example where prudence comes in on this issue. You are advocating the point that a good architect should really consider who is the client of the bundle and what they would expect which I agree with. I think the problem comes in when we get into complex applications with tiers where one tier depends on packages exported from another tier, in this case it is useful to carve out boundaries which limit the spread of import requirements. This really becomes important when you work with distributed applications (as we do in newton) or equally (taking from Mirkos response) a dynamic or constrained environment. Here you want to load the smallest set of bundles to achieve the job in the JVM at any given moment. Consider if you have a distributed application implemented in OSGi here the client and server code share an API packaged in some bundle. But the client does not want or indeed need to load the entire server implementation graph just to use the API. I think the real art in bundle packaging is in limiting the bundle graph to those bundles that the client can reasonably expect to have to import. In general in a complex application an implementation is likely to depend on more packages than it's api. So if you consider making your application distributed or want it to run in a constrained environment it seems prudent to extract the api such that client code can use it without having to resolve the implementation classes. To complete the picture and bring it back to the original question, I'd always /tend/ to separate api, spi and impl into three separate bundles. I'd try to make api depend on as little as possible. I'd make spi depend on api and again on as little else as possible. I'd make impl depend on api and spi. If after doing this impl depended only on api and spi I'd probably consider whether impl was ever likely to get more complicated. If it wasn't then I'd probably collapse back to one bundle. Of course this could always be done prior to building /any/ bundles if you are good at modelling in you head or on paper etc. Good conversation :) Regards, Dave. Peter Kriens wrote: 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 ___ 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. _
Re: [osgi-dev] Put API/SPI/implementation into separate bundles?
2008/6/3 Mirko Jahn <[EMAIL PROTECTED]>: > 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 ;-) > another consideration is when bundles will also be consumed outside of OSGi - especially when the API is common (like aopalliance) and shared amongst several libraries. in that case you'd want the API in a separate jar, to avoid classloader issues outside of OSGi (or you could just force people to use OSGi ;) so +1 for knowing the pros and cons of each approach Just my 2 cents... > > Cheers, > Mirko > ___ > 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?
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
Re: [osgi-dev] Put API/SPI/implementation into separate bundles?
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. Hmm, these client bundles are only bound to the package. Most API code has no (or at least few) uses clauses. This is the beauty of package import, you might be wired to an actual bundle but you never know nor care. Consider if you have an api com.foo and an impl of foo that imports com.bar. If client code wishes to use com.foo in the case where there is only one bundle they also need to resolve com.bar to use classes com.foo Even worse if com.bar imports com.baz...the spider web can get very large and very sticky very quickly... 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. Obviously, if you use Require-Bundle you are out of luck ... but that is a bad pattern anyway. As usual, I seem to be contrarian :-( , but I fail to see what the problem is in packaging API in bundles? Kind regards, Peter Kriens On 2 jun 2008, at 17:35, David Savage wrote: Hi All, 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. Consider if you have an api com.foo and an impl of foo that imports com.bar. If client code wishes to use com.foo in the case where there is only one bundle they also need to resolve com.bar to use classes com.foo Even worse if com.bar imports com.baz...the spider web can get very large and very sticky very quickly... Save your clients time and separate early - you and they will thank you a million times over for it in the end. But agree with sentiment of use common sense consider who the end users of the api are - if it's just internal it's sometimes ok to bend the rules - just be aware of the consequences... Regards, Dave. Mirko Jahn wrote: Here I agree with Jeff. Separating API and implementation on package level is crucial on several different ways. Not only is it a cleaner design, it also gives you the chance to later refactor your code and move the implementation into a new bundle very easily (if you haven't done so already). The question on using different bundles for api/spi/implementation or not is hard to answer in a general manner. I usually ask myself, who is going to use it, how frequently and how likely is it, that there will be several implementations. If it is just internally used, not a major service and not likely to have different implementations, why should I create a (and maintain) a completely different bundle with maybe just one or two classes in it? I think, it is a mixture of common sense and experiences, but if I'm in doubt, I don't separate them. Refactoring is your friend and if the application is done right, it is no problem at all. Just remember to use version ranges on package dependencies and package versioning according to the OSGi Spec. Cheers, Mirko On Mon, Jun 2, 2008 at 3:29 PM, Toni Menzel <[EMAIL PROTECTED]> wrote: You should put API and implementation into separate bundles. This decouples the specification (api) from one or even multiple implementations and allows implementation changes without restarting the framework (the osgi way). When it comes to exporting, well you just export what you either really want to export (usually just api/spi stuff) or you imported yourself (known as package substitution). There are hardly reasons to include the api into the implementation's bundle. Instead you must be aware of class loading issues if you expose services. "Do you even recommend to separate API and SPI on package level?" yes. same as above. (separation of concerns). /Toni Original-Nachricht Datum: Mon, 2 Jun 2008 15:06:39 +0200 Von: "Peter Niederwieser" <[EMAIL PROTECTED]> An: osgi-dev@mail.osgi.org Betreff: [osgi-dev] Put API/SPI/implementation into separate bundles? When
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?
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?
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?
> 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
Re: [osgi-dev] Put API/SPI/implementation into separate bundles?
Hi All, 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. Consider if you have an api com.foo and an impl of foo that imports com.bar. If client code wishes to use com.foo in the case where there is only one bundle they also need to resolve com.bar to use classes com.foo Even worse if com.bar imports com.baz...the spider web can get very large and very sticky very quickly... Save your clients time and separate early - you and they will thank you a million times over for it in the end. But agree with sentiment of use common sense consider who the end users of the api are - if it's just internal it's sometimes ok to bend the rules - just be aware of the consequences... Regards, Dave. Mirko Jahn wrote: Here I agree with Jeff. Separating API and implementation on package level is crucial on several different ways. Not only is it a cleaner design, it also gives you the chance to later refactor your code and move the implementation into a new bundle very easily (if you haven't done so already). The question on using different bundles for api/spi/implementation or not is hard to answer in a general manner. I usually ask myself, who is going to use it, how frequently and how likely is it, that there will be several implementations. If it is just internally used, not a major service and not likely to have different implementations, why should I create a (and maintain) a completely different bundle with maybe just one or two classes in it? I think, it is a mixture of common sense and experiences, but if I'm in doubt, I don't separate them. Refactoring is your friend and if the application is done right, it is no problem at all. Just remember to use version ranges on package dependencies and package versioning according to the OSGi Spec. Cheers, Mirko On Mon, Jun 2, 2008 at 3:29 PM, Toni Menzel <[EMAIL PROTECTED]> wrote: You should put API and implementation into separate bundles. This decouples the specification (api) from one or even multiple implementations and allows implementation changes without restarting the framework (the osgi way). When it comes to exporting, well you just export what you either really want to export (usually just api/spi stuff) or you imported yourself (known as package substitution). There are hardly reasons to include the api into the implementation's bundle. Instead you must be aware of class loading issues if you expose services. "Do you even recommend to separate API and SPI on package level?" yes. same as above. (separation of concerns). /Toni Original-Nachricht Datum: Mon, 2 Jun 2008 15:06:39 +0200 Von: "Peter Niederwieser" <[EMAIL PROTECTED]> An: osgi-dev@mail.osgi.org Betreff: [osgi-dev] Put API/SPI/implementation into separate bundles? When building an OSGi-based system, do you recommend to put a component's API/SPI/implementation into separate bundles, or is it good enough to put them into separate packages (exporting only API and SPI)? Has the "separate bundle" approach advantages when it comes to updating/replacing bundles at runtime? Do you even recommend to separate API and SPI on package level? Cheers, Peter Niederwieser ___ 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 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
Re: [osgi-dev] Put API/SPI/implementation into separate bundles?
Here I agree with Jeff. Separating API and implementation on package level is crucial on several different ways. Not only is it a cleaner design, it also gives you the chance to later refactor your code and move the implementation into a new bundle very easily (if you haven't done so already). The question on using different bundles for api/spi/implementation or not is hard to answer in a general manner. I usually ask myself, who is going to use it, how frequently and how likely is it, that there will be several implementations. If it is just internally used, not a major service and not likely to have different implementations, why should I create a (and maintain) a completely different bundle with maybe just one or two classes in it? I think, it is a mixture of common sense and experiences, but if I'm in doubt, I don't separate them. Refactoring is your friend and if the application is done right, it is no problem at all. Just remember to use version ranges on package dependencies and package versioning according to the OSGi Spec. Cheers, Mirko On Mon, Jun 2, 2008 at 3:29 PM, Toni Menzel <[EMAIL PROTECTED]> wrote: > You should put API and implementation into separate bundles. > This decouples the specification (api) from one or even multiple > implementations and allows implementation changes without restarting the > framework (the osgi way). > > When it comes to exporting, well you just export what you either really want > to export (usually just api/spi stuff) or you imported yourself (known as > package substitution). > > There are hardly reasons to include the api into the implementation's bundle. > Instead you must be aware of class loading issues if you expose services. > > "Do you even recommend to separate API and SPI on package level?" yes. same > as above. (separation of concerns). > > /Toni > > Original-Nachricht >> Datum: Mon, 2 Jun 2008 15:06:39 +0200 >> Von: "Peter Niederwieser" <[EMAIL PROTECTED]> >> An: osgi-dev@mail.osgi.org >> Betreff: [osgi-dev] Put API/SPI/implementation into separate bundles? > >> When building an OSGi-based system, do you recommend to put a >> component's API/SPI/implementation into separate bundles, or is it >> good enough to put them into separate packages (exporting only API and >> SPI)? Has the "separate bundle" approach advantages when it comes to >> updating/replacing bundles at runtime? Do you even recommend to >> separate API and SPI on package level? >> >> Cheers, >> Peter Niederwieser >> ___ >> 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 https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Put API/SPI/implementation into separate bundles?
You should put API and implementation into separate bundles. This decouples the specification (api) from one or even multiple implementations and allows implementation changes without restarting the framework (the osgi way). When it comes to exporting, well you just export what you either really want to export (usually just api/spi stuff) or you imported yourself (known as package substitution). There are hardly reasons to include the api into the implementation's bundle. Instead you must be aware of class loading issues if you expose services. "Do you even recommend to separate API and SPI on package level?" yes. same as above. (separation of concerns). /Toni Original-Nachricht > Datum: Mon, 2 Jun 2008 15:06:39 +0200 > Von: "Peter Niederwieser" <[EMAIL PROTECTED]> > An: osgi-dev@mail.osgi.org > Betreff: [osgi-dev] Put API/SPI/implementation into separate bundles? > When building an OSGi-based system, do you recommend to put a > component's API/SPI/implementation into separate bundles, or is it > good enough to put them into separate packages (exporting only API and > SPI)? Has the "separate bundle" approach advantages when it comes to > updating/replacing bundles at runtime? Do you even recommend to > separate API and SPI on package level? > > Cheers, > Peter Niederwieser > ___ > 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?
Package separation is IMHO the most important thing. If your packages are separate then you can bundle code/API wherever you want. Further, separating API and SPI is essential to your consumers. API and SPI consumers are typically quite different people so clearly stating what they should be using is quite important. The debate over bundling API separate from implementation has raged repeatedly over the past few years with good arguments on both sides. Personally I tend towards bundling them together. That is not a hard rule as the benefits and drawbacks depend somewhat on expected usage patterns. For exmapel, it is easier to manage/build fewer bundles and there are some runtime efficiencies (fewer bundles, classloaders, ...) but on the other hand, lumping things together can make it harder to unobtrusively update the system. A judgement call I'm afraid. Jeff > -Original Message- > From: [EMAIL PROTECTED] [mailto:osgi-dev- > [EMAIL PROTECTED] On Behalf Of Peter Niederwieser > Sent: Monday, June 02, 2008 9:07 AM > To: osgi-dev@mail.osgi.org > Subject: [osgi-dev] Put API/SPI/implementation into separate bundles? > > When building an OSGi-based system, do you recommend to put a > component's API/SPI/implementation into separate bundles, or is it > good enough to put them into separate packages (exporting only API and > SPI)? Has the "separate bundle" approach advantages when it comes to > updating/replacing bundles at runtime? Do you even recommend to > separate API and SPI on package level? > > Cheers, > Peter Niederwieser > ___ > 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-dev] Put API/SPI/implementation into separate bundles?
When building an OSGi-based system, do you recommend to put a component's API/SPI/implementation into separate bundles, or is it good enough to put them into separate packages (exporting only API and SPI)? Has the "separate bundle" approach advantages when it comes to updating/replacing bundles at runtime? Do you even recommend to separate API and SPI on package level? Cheers, Peter Niederwieser ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
