Stuart McCulloch skrev:
On 13/08/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
Karl Pauls wrote:
I'm not sure I really like the idea that we create all those artifacts
of other projects. I was assuming that we would only provide the
wrapper pom's as a starting point for the projects to ultimately make
their stuff available as bundles by themselves.
IMO bundled versions of popular Java libraries is a must if we want to
OSGi to be spread to a large audience. Needing to wrap all dependencies
oneself, is putting a unnecessarily high threshold on starting to use
OSGi. Also, say that I in my own project actually have managed to wrap
all the needed dependencies. What happens when I would like release my
project? If I want to release it in a Maven repository, I have to
provide *own* project specific wrappings of all needed libraries. So we
will have one cocoon-commons-logging-bundle, one
sling-commons-logging-bundle, one directory-commons-logging bundle etc.
It is a much better idea to have an Apache common place for bundling
common libraries. So Felix commons is needed and important!
Now, it would of course be much better if the projects behind popular
libraries took responsibility for bundling their libraries. But that
will not happen in general before OSGi is mainstream, and OSGi will not
become mainstream if the threshold of start to using it is to high.
It might just be me so fell free to ignore this if nobody else has a
strange felling about providing and maintaining all those artifacts...
Actually, I'm not sure if we should provide these wrappers, either. But
if we provide the poms we should provide the binary artifacts as well.
It would be imho a bad idea to release a pom and everyone else is then
able to download this pom and build its own binary. Now, we *could* go
down the road of providing maven archetypes instead, so people can build
their own wrapper pom out of our archetype. But I'm not sure if it's
really worth going this way.
As a user of the artifacts, I'm sure that it is worthwhile ;)
FYI, with the FELIX-308 patch and my changes to Pax-Construct
it should be really easy to generate wrappers for standard libs :)
It is much easier than it was maybe year ago thanks to better tooling.
But it still isn't that easy. I've started to working on making Cocoon
run under OSGi and used some bundles from Felix commons. I'll give some
examples on complications I went through.
I tried to use the Felix Commons version of commons-loggings, but its
required dependency graph was huge. First it imported both log4j
packages and logikit packages instead of having dynamic import or maybe
optional import. This seemed rather pointless for me as I just wanted to
use log4j. The log4j bundling in turn imported javax.mail for some
optional functionality that I don't care for.
After a while I decided to use the commons logging bundle from
spring-osgi instead as it had a far more reasonable dependency graph, at
least if you are going to use it with log4j.
Then I needed a http service that supported Servlet 2.4 (as Cocoon
depends on that version) and went for the Eclipse Jetty http service
(Felix http service supports Servlet 2.3). The Eclipse Jetty http
service in turn depended on a Jetty 5.1.11 bundle and I choose the
Eclipse wrapping of Jetty. Now the Jetty bundle in turn requried
commons.logging;version="[1.0.0,2.0.0) and while the spring-osgi
wrapping of commons logging happened to be version 1.1, it didn't say so
in its package export. So I ended up needing to use the Eclipse wrapping
of Common Logging.
The point of the above story is not to complain of the state of current
library wrappings, the point is to show that wrapping is non trivial. It
requires knowledge about how the wrapped library is supposed to be used.
What package dependencies are required and what are optional. Also
common conventions for, among other things, version requirements are needed.
So good wrapping requires effort. IMO it is better to make that effort
reusable than requiring every OSGi developer to repeat that effort on
his own.
/Daniel
