Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (athena.apache.org: domain of karlpauls@gmail.com
 designates 64.233.182.187 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=PHAt6YiUbZZ9EWkk/Ms9DwhJHAJukLO7u0M1jG+T7egSMf1l0DTZtVTcEui3To6dtQXUgJk5rNl1/mYoImYtv7Yaxm/MnPGhlf+P4dn4f1TspomjmVrZvGk8VChdDg4msQjcwxUHRTb3kvR6zOMBpyccmSksxAMaF4i6tiLCyaY=
Message-ID: <487a994c0708151309q4ba58a1bh22935fccd5bd3d6a@mail.gmail.com>
Date: Wed, 15 Aug 2007 22:09:56 +0200
From: "Karl Pauls" <karlpauls@gmail.com>
To: dev@felix.apache.org
Subject: Re: Releasing Commons
In-Reply-To: <46C34EB8.7020103@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <46A5CAE8.3060005@apache.org>
	 <81f0d9c0708130529p4becd78bqaea2ccba025f2fb9@mail.gmail.com>
	 <46C0D386.1010903@nada.kth.se> <200708141903.10141.niclas@hedhman.org>
	 <46C338D3.9020702@nada.kth.se>
	 <487a994c0708151108j6d61e391gf8142ffb0a4728ce@mail.gmail.com>
	 <46C34345.10607@ungoverned.org> <46C34CB8.8000203@gmail.com>
	 <46C34EB8.7020103@gmx.de>

For the record, this was never about whether we should keep commons
alive or not (at least not for me). This discussion is about whether
and how we start releasing (i.e., officially supporting) parts/all of
the commons wrappers.

That said, I think it is great that we see this kind of support now!

regards,

Karl

On 8/15/07, Toni Menzel <tonimenzel@gmx.de> wrote:
> +1 for keeping commons alive!
> i totally agree with Costin.
> For a (corporate) project i used felix commons quite a lot and was very
> happy that it was acually there!
> If possible i'll provide ported bundles, too of cause!
>
> regards,
> Toni
>
>
> Costin Leau schrieb:
> > +1 from my side in keeping the commons alive.
> > At Spring/OSGi we're thinking of moving the current bundles that we are
> > wrapping to commons.
> > The procedure is not that hard once you get used to it but it definitely
> > raises the bar for OSGi adoption.
> > It's way easier to have these things in a single place and available as
> > a maven download or whatever, then trying to figure out what manifest
> > entries are required, how bndtool works (if you know about that) and
> > then hope that everything works.
> > Most people will just abandon the idea just by thinking of it.
> >
> >
> > Richard S. Hall 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
> >> commons@felix.apache.org 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 <danielf@nada.kth.se> 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
> >>>
> >>>
> >>>
> >
> >
> >
>
> --
> Toni Menzel - Software Developer
> my blog: http://tonitcom.blogspot.com/
> comming soon: http://osgify.com
> contact: tonimenzel@gmx.de
>
>
>


-- 
Karl Pauls
karlpauls@gmail.com