On 8/15/07, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote: > Niclas Hedhman skrev: > > On Tuesday 14 August 2007 05:56, Daniel Fagerstrom wrote: > > > >> I tried to use the Felix Commons version of commons-loggings, but its > >> required dependency graph was huge.
See, that is what I was talking about. This is not an easy task and requires a lot of care to do well. I doubt that we can "just release one wrapper at a time after we thoroughly tested it etc." Either some dependency will not be resolvable or the dependency graph is huge or some stuff is not really working - something will always pop-up. > > Your case is specific to logging[1] and IMHO not really representative. > > > I chose logging as an example as it was the most complicated, but there > where some other libraries that where fairly complicated as well. > > Secondly, you have a strong point that "good wrapping requires effort", > > which > > I totally agree with. And in fact, that is one good reason to question > > the "en masse" wrapping of thrid-party jars that people embarked on here, > > without much second thought whether the bundle would work or not. > Have some trust in community power. If people find it useful there will > be feedback and improvements, and sooner or later it will be good > enough. If people not are interested, it doesn't matter if the quality > is low. But that is the issue. I haven't seen that much activity around it that I would trust in the community (as it is now!). Let's assume we do the release and lots of projects start using our wrappers - I bet sooner rather then later we have to start creating several wrappers per project (to match different versions) then we end-up maintaining 40 something artifacts (in many cases making version decisions for them too). I just have the feeling that this might be a bit to much for us. We already have lots of sub-projects and could start a couple more without even thinking much but we still don't have all the core features implemented. If we now get spammed with questions, feature requests, and bug reports regarding wrapped artifacts ... > > My point > > is, this is a separate concern. > > > > What Stuart is essentially saying is that the Maven Bundle plugin can use a > > POM artifact (housed at Felix, sure) that will do the wrapping at your end > > for you. No need to create a copy of repo1.maven.org which just has > > different > > manifest in the jars and another POM. > > > That is good enough for an in house project. But I'm interested in > running Cocoon under OSGi. If we make that work well we are going to > want to release it. And then all artifacts that we depend on will need > to be in a Maven repository. For me it makes much more sense to have > these common libraries managed and released from Felix than from Cocoon > (and every other Apache project that might go the OSGi way). > > End of the day, every built bundle that is wrapping the same third-party jar > > will be identical (probably some Build-Date entry will differ), without > > effort on your part. Is that bad? Or is it just that you need to use the > > Bundle plugin that bothers you? I think it is just that you assumed that you > > have to put in an effort... > > > I have bundelized a number of libraries with the bundle plugin and am > very happy with it. It is a large improvement compared to previous > bundle build tools. I'll donate them to Felix commons when I find them > stable enough. But if Felix Commons not is going to release anything it > will be of much less use for other Apache projects, like Cocoon. Well, part of this statement makes me question whether we should do it even more. It obviously should be the responsibility of the other Apache projects to make their stuff OSGi compatible. Now assuming we start releasing wrappers for them why would they bother. Isn't the better approach to donate the wrappers to the projects they wrap? > /Daniel Don't get me wrong, I'd love to see other Apache projects start using OSGi and even more supporting it. My only concern is a lot of (more or less) work on the sidelines that slows the development we actually are here to do. regards, Karl -- Karl Pauls [EMAIL PROTECTED]
