A library is a named, versioned collection of bundles that an application programmer wants to deal with as a single entity, similar to an Eclipse feature, but visible in the runtime as a type supporting management and dependency operations.

A suitably tagged façade bundle could be used, as we have already agreed, to represent a library, but that doesn't equate the concepts of library and (large) bundle.

Thanks for the correction; I've updated the blog entry. And indeed, the objections are based upon the headers being non-standard, and as I noted in my post, I hope that they make it into OSGi 4.2 or 5.0 or whatever. I also appreciate that Equinox has used some non-standard ones headers in the past, but at least they've been prefixed Equinox- to clearly delineate ownership of the headers (and the migration path to, say, Bundle-ActivationPolicy has been made now that they are the standard). So on the whole, I think we're agreeing about where it should be going, just not necessarily about the way that it's been done.

[quote post="331"] Firstly, the design intent of the library producer and the library consumers is obscured. Libraries and bundles really are distinct concepts. Secondly, dependency management requires a definitive way of identifying libraries.[/quote]

This is a circular argument. You are asserting that libraries and bundles are really distinct concepts, then using that distinction to claim that you can't use the bundle's dependency management to determine the dependencies. Based on the lemma that libraries and bundles are different, I'd agree with the circular reasoning.

However, I do not believe the lemma holds. What is a library, if not a large bundle? Why should I care how they split it down? If I'm depending on RCP to build my Eclipse application, should I care how it's broken down, or should I just say "I want to depend on RCP"? The Eclipse RCP feature is nothing more than a default grouping of bundles, and there's no reason why a facade bundle cannot be created to represent that (and indeed, hold extra meta-information about the suite of bundles as a whole such as who signed them, where the update site is, and so on).

In fact, your arguments boil down to "We don't like Require-Bundle":

[quote post="331"] A client of a bundle façade would need to access it using Require-Bundle (to avoid the headache of maintaining the list of packages if they used Import-Package) and we are trying to avoid promoting the use of Require-Bundle because of its semantic rough edges, primarily split packages.[/quote]

There may be valid reasons for you not wanting to use Require-Bundle in this way, but claiming that it cannot be used to do this is again circular reasoning. It's perfectly possible to build a facade bundle in this way and use it by clients. Arguably, it protects you against the split-package issues that you can get when one package is separated across many bundles, because the facade can take care of that and not bother the client where they came from (or how they are combined). In fact, this is what is done in a number of cases in Equinox where split packages are common; each split package exports a tagged package, and then one of them imports all the tagged packes and re-exports the package as a whole. This is precisely the behaviour that a facade would do on top of existing bundles.

[quote post="331"]It would not be possible to tell if the intention in using Require-Bundle was to access a library or a bundle, which is important if you accept that libraries and bundles are distinct concepts[/quote]

The point is, I don't. It's a lemma you have taken for granted in your entire post, and has been used as the supporting argument in most of what you say. What I'm challenging you is to describe why they are distinct concepts. After all, modularity is as much about composition as it is about components; why can't we combine components together and treat them as a larger component? The J2EE spec is merely an aggregation of other specs, but is treated as a (large) component in its own right, albeit with optional dependencies. Similarly, people can write an application that depends on Spring DM, but that doesn't mean that they are using every component that is part of the Spring DM system.

Why must a bundle only be the lowest-level granular component, and why can't it be aggregated? Why invent an artificial distinction and talk about 'library' and 'bundle'? Is Log4J a bundle or a library? What about Xerces? What about Tomcat? What about JBoss? Why and how do you decide to transition between one term and another in that sequence of ever-increasing sized systems, and importantly, as the person who uses those systems and doesn't care about the internal implementation details, why do I care about a difference in terminology when 'my app uses Log4j or Xerces or Tomcat or JBoss'. I don't care whether it's implemented in one big blob or two smaller blobs or fifteen smaller blobs; I depend on the aggregation, not each individually.

The disadvantages of using a bundle façade as a way of implementing a library are as follows. Firstly, the design intent of the library producer and the library consumers is obscured. Libraries and bundles really are distinct concepts. Secondly, dependency management requires a definitive way of identifying libraries. Using the absence of a bundle activator is too weak as subsidiary bundles of an application do not need a bundle activator. Indeed, when Spring DM is used, application bundles do not need bundle activators at all. So we'd need to introduce a non-standard header to indicate libraries. Thirdly, there's the usage model. A client of a bundle façade would need to access it using Require-Bundle (to avoid the headache of maintaining the list of packages if they used Import-Package) and we are trying to avoid promoting the use of Require-Bundle because of its semantic rough edges, primarily split packages. Plus it would not be possible to tell if the intention in using Require-Bundle was to access a library or a bundle, which is important if you accept that libraries and bundles are distinct concepts. Fourthly, split packages would become a significant risk when customers and third parties define their own libraries. The Platform completely avoids this risk by building on Import-Package semantics.

So the main objection to the use of non-standard headers seems to be that they are non-standard. But consider how some of the OSGi R4 facilities such as Require-Bundle and fragment bundles came into existence. They were implemented in Eclipse as non-standard extensions of OSGi R3 (without any special Eclipse prefix on the header names) and then adopted into OSGi R4 through participation of several Eclipse developers in the OSGi standards work. SpringSource is adopting a similar approach when we see requirements of customers of the Platform that are not satisfied by OSGi R4.1. We're hosting the next face to face meeting of the Core Platform and Enterprise Expert Groups next week. Apart from debating the approach taken by the Platform, we'll be explaining the requirements and rationale. If there really are missing facilities in the OSGi standard, then I would expect suitable generalisations of our solutions to find their way into a future version of the standard.

This is a healthy way for the standard to evolve: proving certain features in the field before adopting them for standardisation. For instance, I fully expect some of our non-standard facilities will remain non-standard and only of interest to Spring users.

Finally, I would like to correct your statement "The only problem with the repository is the use of non-standard headers (which many don't like)". All bundles in the SpringSource Enterprise Bundle Repository use only OSGi standard headers as a matter of policy. We even take care to expunge non-standard headers left over from tools such as bnd.

Note that this provides a further justification for not using bundle façades to represent libraries. We include various library definitions in the repository. If we included bundle façades then these would need to include non-standard headers to clearly identify them as libraries, as reasoned above, and then we would deviate from our own policy of only including OSGi standard headers in bundles in the repository.

Regards,
Glyn

I've written up my thoughts at http://alblue.blogspot.com/2008/05/springsource-app-platform-and-bundle.html and in particular, refute your thought that the dependency information can't be found:

[quote post="331"]Consider a situation where a library is deployed into the Platform and then some applications are deployed that import the library. Later an administrator comes along and is considering upgrading the library and wants to know which applications currently depend upon it to assess the impact. The runtime needs to be able to report the dependencies at the level of applications and libraries.
[/quote]

That's trivial to do if the library is itself a bundle, because you can use the PlatformAdmin to find out what bundles you depend on. One can thus easily find all the applications depend on that 'library' bundle, and it doesn't need any non-standard wiring headers to make that happen. If using naming conventions isn't enough (e.g. hibernate-library etc.) then it's easy enough to add a marker header into the manifest that identifies that as a library bundle – though one might also do that by other means (for example, the way that Knopflerfish identifies library bundles is by listing those without a Bundle-Activator). My main point is that this is all trivially possible to do in the current dependency environment without needing to create additional dependency headers, and that's what I think should have been done here.

Ok, understood. Sorry for misunderstanding.

Agree split packages and can be a major pain with Require-Bundle, so I can see the intent of Import-Bundle.

It just seems the real value of statements like Import-Bundle would be at build time. Certainly validating at runtime is useful but there wouldn't need to be validation if the extension headers didn't exist?

I'll stop hogging the list, seems we think there are different solutions which I'm happy to agree on

Regards,

Dave[/quote]

Thanks Dave.

Glyn

Ok, understood. Sorry for misunderstanding.

Agree split packages and can be a major pain with Require-Bundle, so I can see the intent of Import-Bundle.

It just seems the real value of statements like Import-Bundle would be at build time. Certainly validating at runtime is useful but there wouldn't need to be validation if the extension headers didn't exist?

I'll stop hogging the list, seems we think there are different solutions which I'm happy to agree on

Regards,

Dave

Yep agree there is a problem, but not on the solution – makings of a fun discussion

[quote post="331"]I agree the tooling should give early warning of such problems. A further advantage of processing the headers at runtime is that it allows the Platform to provide diagnostics and other feedback in terms of the developer's inputs.[/quote]

Are you suggesting the application server can modify your bundle to resolve any problems at deployment time? If so I'm not sure how this works with version control systems – if the system gets restarted do you need to manually refix each bundle each time? It seems to me build or development time tools could still have feedback but generate standard osgi bundles in the end and do so in a way that worked with version control.

Regards,

Dave[/quote]

I'm suggesting no such thing, so I'm sorry that I somehow gave you that impression!

As I said in the post, the Platform detects the situation where a bundle imports two or more libraries which export a common package, issues an appropriate log message, and fails to install the importing bundle.

I was simply making the point that the tooling could provide prior warning of that situation and prompt the developer to fix it before deploying to the Platform. This would prevent the "nasty surprise" you alluded to.

Glyn

[quote comment=\"105679\"]I\'m not convinced of the difference between Require-Bundle and Import-Bundle.[/quote]

Then I guess you\'ve never had to grapple with a split package.

[quote comment=\"105679\"]I especially don\'t see the need of Import-Library, either.

You could easily have a single bundle which represented hibernate-as-a-whole and solely existed to provide wiring for importing packages (exported to the client). A bundle like:

Bundle-Name: hibernate
Bundle-Version: 1.2.3
Require-Bundle: org.hibernate.foo;visibility:=reexport

would have the same ability to have the dependencies on the bundle generally. The org.hibernate.foo could import packages as appropriate and then export them if needed. You still get the loose coupling about what is in the \'hibernate\' package, and can get the packages from there.

\"Any problem can be solved by an extra level of indirection\"[/quote]

Yes, it is certainly possible to use a \"visibility:=reexport\" façade as a way of implementing libraries, but the design intent gets lost along the way and you have to resort to some careful naming conventions if the runtime is to \"understand\" libraries and manage them in any meaningful way.

Consider a situation where a library is deployed into the Platform and then some applications are deployed that import the library. Later an administrator comes along and is considering upgrading the library and wants to know which applications currently depend upon it to assess the impact. The runtime needs to be able to report the dependencies at the level of applications and libraries.

Glyn

Yep agree there is a problem, but not on the solution – makings of a fun discussion

[quote post="331"]I agree the tooling should give early warning of such problems. A further advantage of processing the headers at runtime is that it allows the Platform to provide diagnostics and other feedback in terms of the developer's inputs.[/quote]

Are you suggesting the application server can modify your bundle to resolve any problems at deployment time? If so I'm not sure how this works with version control systems – if the system gets restarted do you need to manually refix each bundle each time? It seems to me build or development time tools could still have feedback but generate standard osgi bundles in the end and do so in a way that worked with version control.

Regards,

Dave

You could easily have a single bundle which represented hibernate-as-a-whole and solely existed to provide wiring for importing packages (exported to the client). A bundle like:

Bundle-Name: hibernate
Bundle-Version: 1.2.3
Require-Bundle: org.hibernate.foo;visibility:=reexport

would have the same ability to have the dependencies on the bundle generally. The org.hibernate.foo could import packages as appropriate and then export them if needed. You still get the loose coupling about what is in the 'hibernate' package, and can get the packages from there.

"Any problem can be solved by an extra level of indirection"

Alex