As I said in the beginning, I'm not sure either but would like to see more usage/activity around it first but it certainly is not the end of the world -- so again, feel free to ignore me.
At least it is good to see somebody like Daniel and Carsten supporting it (that is certainly a start). regards, Karl On 8/15/07, Richard S. Hall <[EMAIL PROTECTED]> wrote: > While I understand Karl's concerns, my view of Commons is that it is a > convenience service offered by us as a means to jump start OSGi/Felix usage. > > It seems like if we make this stuff available with a generous portion of > caveats, then we could still do it. Heck, we can even create a > [EMAIL PROTECTED] mailing list if the traffic gets too big. > Somehow I doubt it will come to that. > > As long as we have Carsten motivated to work on it, I say move forward > with it. I don't think there is any reason to sit here and worry about > Commons being too big of a success, since it will take a long time for > that to happen anyway and if it does happen then we will probably have > more people willing to work on it. > > -> richard > > Karl Pauls wrote: > > 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]
