Releasing Commons

[Carsten Ziegeler <cz...@apache.org>]

Hi,

I updated our commons project, main changes are:
- parent pom is now in "pom" (similar to our root pom)
- convenience pom under /commons to build the whole tree
- Only released artifacts are used (maven-bundle-plugin:1.0.0,
root-pom:1.0.0)
- information for the mvn release/gpg plugin to use mvn for release
  (If this works out, we can add this info to the felix root pom later
on - adding it now would require to re-release the root pom in order to
be able to release the commons pom)
- changed the artifactid for the commons pom from "build" to
"commons-build" (more unique name)
- all versions are 1.0.0-SNAPSHOT

With these changes I would like to release the commons parent pom,
followed by the bundles and then call a vote on all these artifacts.

If noone objects (lazy consensus...) I'll go ahead in the next days.

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Releasing Commons

[Roland Weber <os...@dubioso.net>]

Hi Carsten,

HttpComponents is also Maven2-based. Oleg has collected his actions
for a release in our Wiki, you may want to have a look at that (and
build a similar page for Felix?):
http://wiki.apache.org/jakarta-httpclient/HttpComponentsCoreReleaseProcess

It's way more than just calling Maven...

>> Second step to release Commons would be a proper release with tarball /dist 
>> > stuff, and requires Vote of the PMC for legal reasons.
> 
> Yes, this raises the question of how the release of commons should look
> like. So far I thought about just releasing the pom and the jar - not
> sure if we need a src and bin dist here?

Well, you need a LICENCE and NOTICE file, and probably should
have at least a minimal README. Keeping them hidden in the JAR
will make the release different from all other distributables
at Apache, right?
Whether you want to release sources is of course a community
decision. But since it's Open Source Software, you probably
want to make the source for a particular release a little more
accessible than by posting a link to a Subversion tag? The people
that use the binary are supposed to look into the corresponding
source when they hit problems.

cheers,
  Roland

PS: I'm only subscribed to the list digest, don't know whether
the copy to the list will go through. Feel free to quote or
forward this mail if it doesn't.

Re: Releasing Commons

[Niclas Hedhman <ni...@hedhman.org>]

On Tuesday 07 August 2007 05:47, Karl Pauls wrote:

> I'm not sure I really like the idea that we create all those artifacts
> of other projects. 

I am sort of -0 on this topic. And that is why Pax Construct (www.ops4j.org) 
exists, so it is easy to create and maintain those wrappers "at home" and not 
depend on which variant someone else has decided upon.

As Marcel is hinting, having a Commons with other people's, non OSGi 
considered, code in it, Felix project is taking on itself to be a target of 
frustration when such a bundle doesn't work as expected, perhaps due to OSGi 
aspects interfering with the 'architecture' of the wrapped jar. I think it is 
probably better to avoid this altogether, and if it is still wanted, stick 
those elsewhere.


Cheers
Niclas

Re: Releasing Commons

[Karl Pauls <ka...@gmail.com>]

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 <he...@ungoverned.org> 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 <da...@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
> >
> >
>


-- 
Karl Pauls
karlpauls@gmail.com

Re: Releasing Commons

[Stuart McCulloch <st...@jayway.net>]

On 16/08/07, Richard S. Hall <he...@ungoverned.org> 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.


access to OSGi-ready bundles of common libraries is certainly a question
that's being asked more and more these days - some days it seems more
frequent than 'how do I create my first bundle' :)

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.


+1 for at least trying a few releases and see how it goes

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.


I'm also willing to help out with commons where needed

btw, has anyone thought about not just providing wrapper poms,
but perhaps adding basic 'fit-for-purpose' tests to check that the
wrapped bundle works ok in OSGi?  This would be added value :)

-> richard
>
> Karl Pauls wrote:
> > On 8/15/07, Daniel Fagerstrom <da...@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
> >
> >
>



-- 
Cheers, Stuart

Re: Releasing Commons

[Karl Pauls <ka...@gmail.com>]

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 <to...@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 <da...@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

Re: Releasing Commons

[Toni Menzel <to...@gmx.de>]

+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 <da...@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

Re: Releasing Commons

[Costin Leau <co...@gmail.com>]

+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 <da...@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
>>
>>   
> 


-- 
Costin

Re: Releasing Commons

["Richard S. Hall" <he...@ungoverned.org>]

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 <da...@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
>
>   

Re: Releasing Commons

[Karl Pauls <ka...@gmail.com>]

On 8/15/07, Daniel Fagerstrom <da...@nada.kth.se> wrote:
> Karl Pauls skrev:
> > On 8/15/07, Daniel Fagerstrom <da...@nada.kth.se> wrote:
> >
> >> Niclas Hedhman skrev:
> >>
> >>> On Tuesday 14 August 2007 05:56, Daniel Fagerstrom wrote:
> >>>
> ...
> >> 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 understand your concern and can agree about that it might be to early
> to release Felix commons now. Several of the bundles I have looked at
> could need some more polishing before they are ready for a release.
>
> I think automated snapshot releases of Felix Commons to some Maven
> repository would be a reasonable level. It makes it easy to use the
> artifacts for other projects (I have no problem with checking out and
> build Felix, but it increases the threshold for my co-developers to get
> started with OSGi). At the same time is a snapshot release not much of a
> commitment from the Felix community, no one expect the snapshot releases
> to be forever back compatible or even released.

Sure. I wouldn't mind snapshot releases at all (in fact I was assuming
we do that already :-).

regards,

Karl

> > 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 ...
> >
> That might be part of it if Felix Commons is successful. But as Felix is
> a volunteer effort, no one has even the slightest right to ask you to do
> anything about it if you don't feel like it. But that is normally only a
> (small) part of the story for a successful subproject, what the
> community also get is that interested people generate patches and
> oversight and that the community becomes larger.
>
> /Daniel
>
>


-- 
Karl Pauls
karlpauls@gmail.com

Re: Releasing Commons

[Stuart McCulloch <st...@jayway.net>]

On 16/08/07, Daniel Fagerstrom <da...@nada.kth.se> wrote:
>
> Karl Pauls skrev:
> > On 8/15/07, Daniel Fagerstrom <da...@nada.kth.se> wrote:
> >
> >> Niclas Hedhman skrev:
> >>
> >>> On Tuesday 14 August 2007 05:56, Daniel Fagerstrom wrote:
> >>>
> ...
> >> 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 understand your concern and can agree about that it might be to early
> to release Felix commons now. Several of the bundles I have looked at
> could need some more polishing before they are ready for a release.
>
> I think automated snapshot releases of Felix Commons to some Maven
> repository would be a reasonable level.


releasing snapshots is a good idea, but I'd suggest *not* using the central
snapshots repo, as that tends to pull in all sorts of other maven snapshots
when you add it to your project :)

It makes it easy to use the
> artifacts for other projects (I have no problem with checking out and
> build Felix, but it increases the threshold for my co-developers to get
> started with OSGi). At the same time is a snapshot release not much of a
> commitment from the Felix community, no one expect the snapshot releases
> to be forever back compatible or even released.
>
> > 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 ...
> >
> That might be part of it if Felix Commons is successful. But as Felix is
> a volunteer effort, no one has even the slightest right to ask you to do
> anything about it if you don't feel like it. But that is normally only a
> (small) part of the story for a successful subproject, what the
> community also get is that interested people generate patches and
> oversight and that the community becomes larger.


I also think it has the benefit of spreading the Felix name and
could bring more people over to try out the framework instead
of just defaulting to Equinox/Eclipse

/Daniel
>
>
-- 
Cheers, Stuart

Re: Releasing Commons

[Daniel Fagerstrom <da...@nada.kth.se>]

Karl Pauls skrev:
> On 8/15/07, Daniel Fagerstrom <da...@nada.kth.se> wrote:
>   
>> Niclas Hedhman skrev:
>>     
>>> On Tuesday 14 August 2007 05:56, Daniel Fagerstrom wrote:
>>>       
...
>> 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 understand your concern and can agree about that it might be to early 
to release Felix commons now. Several of the bundles I have looked at 
could need some more polishing before they are ready for a release.

I think automated snapshot releases of Felix Commons to some Maven 
repository would be a reasonable level. It makes it easy to use the 
artifacts for other projects (I have no problem with checking out and 
build Felix, but it increases the threshold for my co-developers to get 
started with OSGi). At the same time is a snapshot release not much of a 
commitment from the Felix community, no one expect the snapshot releases 
to be forever back compatible or even released.

> 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 ...
>   
That might be part of it if Felix Commons is successful. But as Felix is 
a volunteer effort, no one has even the slightest right to ask you to do 
anything about it if you don't feel like it. But that is normally only a 
(small) part of the story for a successful subproject, what the 
community also get is that interested people generate patches and 
oversight and that the community becomes larger.

/Daniel

Re: Releasing Commons

[Karl Pauls <ka...@gmail.com>]

On 8/15/07, Daniel Fagerstrom <da...@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

-- 
Karl Pauls
karlpauls@gmail.com

Re: Releasing Commons

[Daniel Fagerstrom <da...@nada.kth.se>]

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.
>>     
> 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.
>  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.

/Daniel

Re: Releasing Commons

[Carsten Ziegeler <cz...@apache.org>]

Niclas Hedhman wrote:
> 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.
> 
> Your case is specific to logging[1] and IMHO not really representative. 
> 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. 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.
> 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...
> 
Hmm, I think for inhouse development this is fine, but what about open
source projects? Of course this depends on the distribution of such a
project, but if it wants to provide a "download everything in one go"
distribution, it has to built these wrappers as well. And this has to be
done by each and every project which does it this way. Which obviously
duplicates the effort.

So, this puts me into the "we should provide commons"-camp, again :)

But the concerns raised here are of course valid: we should only provide
a wrapper bundle, if we are sure that it works as expected. But as I
said in a previous mail, I don't see a propblem if we do proper voting
on such a candidate. If three people think that it works as expected
this should be enough as a verification I think.

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Releasing Commons

[Niclas Hedhman <ni...@hedhman.org>]

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.

Your case is specific to logging[1] and IMHO not really representative. 
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. 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.
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...


Cheers
-- 
Niclas Hedhman, Software Developer

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug


[1] Just use Pax Logging and all your logging problems should be gone (or I 
promise I'll do all I can to fix them.) Soon will release a 1.0 version, when 
I have managed to run it against the OSGi Alliance TCK.

Re: Releasing Commons

[Daniel Fagerstrom <da...@nada.kth.se>]

Stuart McCulloch skrev:
> On 13/08/07, Carsten Ziegeler <cz...@apache.org> 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

Re: Releasing Commons

[Stuart McCulloch <st...@jayway.net>]

On 13/08/07, Carsten Ziegeler <cz...@apache.org> 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.
> >
> > 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.


FYI, with the FELIX-308 patch and my changes to Pax-Construct
it should be really easy to generate wrappers for standard libs :)

In addition, if we provide these wrappers I think we should open the
> next door and provide an obr as well :)
>
> So, I think either we go the full way (pom+bin+obr) or we leave the
> wrapper bundles to others and remove commons altogether. Personally, I'm
> fine with both alternatives.
>
> Carsten
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>



-- 
Cheers, Stuart

Re: Releasing Commons

[Carsten Ziegeler <cz...@apache.org>]

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.
> 
> 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.

In addition, if we provide these wrappers I think we should open the
next door and provide an obr as well :)

So, I think either we go the full way (pom+bin+obr) or we leave the
wrapper bundles to others and remove commons altogether. Personally, I'm
fine with both alternatives.

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Releasing Commons

[Marcel Offermans <ma...@luminis.nl>]

On Aug 6, 2007, at 23:47 , Karl Pauls wrote:

> 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...

I agree the most natural place for maintaining those artifacts, which  
basically just add meta-data to the existing libraries, would be the  
commons project itself. The same goes for the Maven plugins we are  
maintaining now. Perhaps we should really make an effort to get them  
included in those projects. Perhaps the people within Felix that  
maintain them now can keep maintaining them as part of those projects.

On the other hand, if those projects have no interest at all in  
maintaining them, then I think we should somehow make them available  
ourselves. That might just mean having them in our repository for  
interested parties to use themselves though.

I guess we are at a point where we should start considering what we  
actually want to release as part of Felix. I mean we have a lot of  
bundles in our repository, and we have been working hard to get the  
core released. Now that that is done, we can start looking at other  
stuff, and I think we should come up with some kind of policy for  
doing releases of bundles (or subprojects). What quality standards do  
we want to impose upon ourselves? When is a bundle ready for release?  
Does it need unit tests? A certain amount of code coverage? Design  
and user documentation? Which bundles are actually used in "real  
world" projects now? I think it's important that we can be proud of  
the things we release, and be confident that we've done our absolute  
best to make sure they actually work well.

Perhaps I'm rambling on a bit here... feel free to give your opinion  
on this! :)

Greetings, Marcel

Re: Releasing Commons

[Karl Pauls <ka...@gmail.com>]

On 7/26/07, Carsten Ziegeler <cz...@apache.org> wrote:
> Niclas Hedhman wrote:
> > On Tuesday 24 July 2007 20:53, Carsten Ziegeler wrote:
> >> Now, I have the hope that releasing is just a matter of invoking maven
> >> (with the correct arguments).
> >
> > First step is just the production of a parent pom, for the Commons to depend
> > on. IMHO, that is not really a release (no tarball) and can be done by lazy
> > consensus (go ahead).
> Yes, I agree - good idea.
>
> >
> > Second step to release Commons would be a proper release with tarball /dist
> > stuff, and requires Vote of the PMC for legal reasons.
> Yes, this raises the question of how the release of commons should look
> like. So far I thought about just releasing the pom and the jar - not
> sure if we need a src and bin dist here?

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.

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...

regards,

Karl

> > IMHO, Carsten is more than qualified to handle these things, as he has
> > released Cocoon several times in the past, which is one hell of a beast...
> > So, don't hinder the guy ;o)
> Thanks - now you put even more pressure on me :)
>
> Carsten
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>


-- 
Karl Pauls
karlpauls@gmail.com

Re: Releasing Commons

[Carsten Ziegeler <cz...@apache.org>]

Niclas Hedhman wrote:
> On Tuesday 24 July 2007 20:53, Carsten Ziegeler wrote:
>> Now, I have the hope that releasing is just a matter of invoking maven
>> (with the correct arguments).
> 
> First step is just the production of a parent pom, for the Commons to depend 
> on. IMHO, that is not really a release (no tarball) and can be done by lazy 
> consensus (go ahead).
Yes, I agree - good idea.

> 
> Second step to release Commons would be a proper release with tarball /dist 
> stuff, and requires Vote of the PMC for legal reasons.
Yes, this raises the question of how the release of commons should look
like. So far I thought about just releasing the pom and the jar - not
sure if we need a src and bin dist here?

> 
> IMHO, Carsten is more than qualified to handle these things, as he has 
> released Cocoon several times in the past, which is one hell of a beast... 
> So, don't hinder the guy ;o)
Thanks - now you put even more pressure on me :)

Carsten


-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Releasing Commons

[Niclas Hedhman <ni...@hedhman.org>]

On Tuesday 24 July 2007 20:53, Carsten Ziegeler wrote:
> Now, I have the hope that releasing is just a matter of invoking maven
> (with the correct arguments).

First step is just the production of a parent pom, for the Commons to depend 
on. IMHO, that is not really a release (no tarball) and can be done by lazy 
consensus (go ahead).

Second step to release Commons would be a proper release with tarball /dist 
stuff, and requires Vote of the PMC for legal reasons.

IMHO, Carsten is more than qualified to handle these things, as he has 
released Cocoon several times in the past, which is one hell of a beast... 
So, don't hinder the guy ;o)


Cheers
Niclas

Re: Releasing Commons

[Karl Pauls <ka...@gmail.com>]

On 7/27/07, Karl Pauls <ka...@gmail.com> wrote:
> On 7/24/07, Carsten Ziegeler <cz...@apache.org> wrote:
> > Marcel Offermans wrote:
> > >
> > > I agree that it's a lot of work for one person, and dividing the
> > > responsibility might be a good idea, Felix is a complicated project that
> > > consists of many components. In theory each component can be released
> > > independently. My only "worry" is that we create many different ways and
> > > policies for creating releases. That won't look good.
> > Yes, you're absolutly right - and it's good that you raised your
> > concerns and voiced your opinion about the whole topic!
> > Now, I have the hope that releasing is just a matter of invoking maven
> > (with the correct arguments). For commons this should work now (haven't
> > testet yet) and I'm pretty sure we can do the same for the rest of Felix
> > as well. So, in theory - with this in place - everybody could do the
> > release - and all releases would work the same.
> >
> > > So I would want to
> > > discuss this with Karl present to make sure we all agree on how to do
> > > this (of course anybody else is free to join in on this discussion).
> > > However, I don't want to "stop" anybody from contributing, I really
> > > appreciate the effort you're making.
> > You're right that this is a bad timing :) I just waited for the release
> > of the parent pom and the maven bundle plugin. We are not in a hurry
> > although I personaly would have released commons rather earlier than
> > later. So it is only fair if we wait for Karl and see what he thinks.
>
> I'll be back starting the 6th of August. It would be nice if you could
> hold it for this one week (my connection status doesn't allow for any
> real discussion atm).
>
> regards,
>
> Karl

Thanks for waiting. I'll reply to some of the mails in this thread
separately in order to address the different subjects.

regards,

Karl

> > Carsten
> > --
> > Carsten Ziegeler
> > cziegeler@apache.org
> >
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>


-- 
Karl Pauls
karlpauls@gmail.com

Re: Releasing Commons

[Karl Pauls <ka...@gmail.com>]

On 7/24/07, Carsten Ziegeler <cz...@apache.org> wrote:
> Marcel Offermans wrote:
> >
> > I agree that it's a lot of work for one person, and dividing the
> > responsibility might be a good idea, Felix is a complicated project that
> > consists of many components. In theory each component can be released
> > independently. My only "worry" is that we create many different ways and
> > policies for creating releases. That won't look good.
> Yes, you're absolutly right - and it's good that you raised your
> concerns and voiced your opinion about the whole topic!
> Now, I have the hope that releasing is just a matter of invoking maven
> (with the correct arguments). For commons this should work now (haven't
> testet yet) and I'm pretty sure we can do the same for the rest of Felix
> as well. So, in theory - with this in place - everybody could do the
> release - and all releases would work the same.
>
> > So I would want to
> > discuss this with Karl present to make sure we all agree on how to do
> > this (of course anybody else is free to join in on this discussion).
> > However, I don't want to "stop" anybody from contributing, I really
> > appreciate the effort you're making.
> You're right that this is a bad timing :) I just waited for the release
> of the parent pom and the maven bundle plugin. We are not in a hurry
> although I personaly would have released commons rather earlier than
> later. So it is only fair if we wait for Karl and see what he thinks.

I'll be back starting the 6th of August. It would be nice if you could
hold it for this one week (my connection status doesn't allow for any
real discussion atm).

regards,

Karl

> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
>


-- 
Karl Pauls
karlpauls@gmail.com

Re: Releasing Commons

[Carsten Ziegeler <cz...@apache.org>]

Marcel Offermans wrote:
> 
> I agree that it's a lot of work for one person, and dividing the
> responsibility might be a good idea, Felix is a complicated project that
> consists of many components. In theory each component can be released
> independently. My only "worry" is that we create many different ways and
> policies for creating releases. That won't look good.
Yes, you're absolutly right - and it's good that you raised your
concerns and voiced your opinion about the whole topic!
Now, I have the hope that releasing is just a matter of invoking maven
(with the correct arguments). For commons this should work now (haven't
testet yet) and I'm pretty sure we can do the same for the rest of Felix
as well. So, in theory - with this in place - everybody could do the
release - and all releases would work the same.

> So I would want to
> discuss this with Karl present to make sure we all agree on how to do
> this (of course anybody else is free to join in on this discussion).
> However, I don't want to "stop" anybody from contributing, I really
> appreciate the effort you're making.
You're right that this is a bad timing :) I just waited for the release
of the parent pom and the maven bundle plugin. We are not in a hurry
although I personaly would have released commons rather earlier than
later. So it is only fair if we wait for Karl and see what he thinks.

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Releasing Commons

[Marcel Offermans <ma...@luminis.nl>]

On Jul 24, 2007, at 13:24 , Carsten Ziegeler wrote:

> Marcel Offermans wrote:
>> First of all, don't take this the wrong way, but I thought that  
>> only our
>> release manager could call a vote for releasing artifacts?

> This is up to us to define this. There is no official position of a
> release manager in an apache project. But it's common sense to apoint
> someone to do this stuff. Depending on the work/project there is only
> one release manager or several. It makes sense to define who is
> responsible for releasing what in order to avoid confusion. But that's
> up to the project to define this.

Okay, thanks for clearing that up for me!

I agree that it's a lot of work for one person, and dividing the  
responsibility might be a good idea, Felix is a complicated project  
that consists of many components. In theory each component can be  
released independently. My only "worry" is that we create many  
different ways and policies for creating releases. That won't look  
good. So I would want to discuss this with Karl present to make sure  
we all agree on how to do this (of course anybody else is free to  
join in on this discussion). However, I don't want to "stop" anybody  
from contributing, I really appreciate the effort you're making.

Greetings, Marcel

Re: Releasing Commons

[Alin Dreghiciu <ad...@gmail.com>]

Related strictly to commons I would suggest that the one in charge with
releasing should be somebody that can allocate time to this process as I
presume that commons will be released very often due to the nature of this
subproject. If we are looking back as Karl was bussy there was quite a gap
between posting of a new wrapped jar and the time it got released.
Regards,
Alin Dreghiciu

On 7/24/07, Carsten Ziegeler <cz...@apache.org> wrote:
>
> Marcel Offermans wrote:
> > First of all, don't take this the wrong way, but I thought that only our
> > release manager could call a vote for releasing artifacts?
> This is up to us to define this. There is no official position of a
> release manager in an apache project. But it's common sense to apoint
> someone to do this stuff. Depending on the work/project there is only
> one release manager or several. It makes sense to define who is
> responsible for releasing what in order to avoid confusion. But that's
> up to the project to define this.
>
> Having one release manager adds all the work to one single person (which
> can get very annoying over time) and also can lead to problems over
> time. What if a release is required and the release manager is not
> available? etc.
>
> But everyone can start a vote on something :)
>
> I personally think that it makes sense to split up the work for the
> release as Felix is a hugh project with many artifacts. And my idea was
> to help out in uncritical areas like commons. It has nearly no
> dependencies to the rest of Felix.
>
> > I happen to
> > know he's on holiday for the next two weeks. Furthermore, we still are
> > in the middle of releasing the framework itself, so I would suggest we
> > include these artifacts in the next build. Richard already mentioned
> > wanting to do an 1.0.1 soonish, so together with these artifacts that
> > would make a good second release.
> Hmm, yes this is one possibility - but as there are many modules in
> commons I personally would do a separate release of these. It's
> independent and doing a 1.0.1 release of the framework has no effect on
> commons.
>
> So, its up to us if we want to load all the work onto Karl (who did a
> great job btw). In general, if someone is willing to scratch an itch, I
> wouldn't stop him or her - but that's my personal opinion. And I'm fine
> with whatever we all think is best.
>
> Carsten
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>

Re: Releasing Commons

[Carsten Ziegeler <cz...@apache.org>]

Marcel Offermans wrote:
> First of all, don't take this the wrong way, but I thought that only our
> release manager could call a vote for releasing artifacts?
This is up to us to define this. There is no official position of a
release manager in an apache project. But it's common sense to apoint
someone to do this stuff. Depending on the work/project there is only
one release manager or several. It makes sense to define who is
responsible for releasing what in order to avoid confusion. But that's
up to the project to define this.

Having one release manager adds all the work to one single person (which
can get very annoying over time) and also can lead to problems over
time. What if a release is required and the release manager is not
available? etc.

But everyone can start a vote on something :)

I personally think that it makes sense to split up the work for the
release as Felix is a hugh project with many artifacts. And my idea was
to help out in uncritical areas like commons. It has nearly no
dependencies to the rest of Felix.

> I happen to
> know he's on holiday for the next two weeks. Furthermore, we still are
> in the middle of releasing the framework itself, so I would suggest we
> include these artifacts in the next build. Richard already mentioned
> wanting to do an 1.0.1 soonish, so together with these artifacts that
> would make a good second release.
Hmm, yes this is one possibility - but as there are many modules in
commons I personally would do a separate release of these. It's
independent and doing a 1.0.1 release of the framework has no effect on
commons.

So, its up to us if we want to load all the work onto Karl (who did a
great job btw). In general, if someone is willing to scratch an itch, I
wouldn't stop him or her - but that's my personal opinion. And I'm fine
with whatever we all think is best.

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Releasing Commons

[Marcel Offermans <ma...@luminis.nl>]

Hello Carsten,

On Jul 24, 2007, at 11:48 , Carsten Ziegeler wrote:

> With these changes I would like to release the commons parent pom,
> followed by the bundles and then call a vote on all these artifacts.
>
> If noone objects (lazy consensus...) I'll go ahead in the next days.

First of all, don't take this the wrong way, but I thought that only  
our release manager could call a vote for releasing artifacts? I  
happen to know he's on holiday for the next two weeks. Furthermore,  
we still are in the middle of releasing the framework itself, so I  
would suggest we include these artifacts in the next build. Richard  
already mentioned wanting to do an 1.0.1 soonish, so together with  
these artifacts that would make a good second release.

Greetings, Marcel

Re: Releasing Commons

[Carsten Ziegeler <cz...@apache.org>]

Karl Pauls wrote:
> I have to admit that I didn't follow the progress of commons that
> closely (so it's great that we see progress again!). I do remember
> however that there was some concern about the idea some while back
> about the problem that some of the wrapped projects might not work
> properly in an OSGi environment. So I guess my overall question in
> regard to releasing commons is, have you actually tried all of the
> resulting artifacts and think they do what they are supposed to do (or
> somebody else)?
> 
Yes, this is a good point - we are using quiet a few of them and they
work for us :) But anyway, that's the point of voting. As soon as we put
one of them up for a vote, everyone should only give a +1 if she really
thinks that everything is fine with the artifact and that might include
having a working version. So, if we don't gather three binding votes,
the artifact will not be released.

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Releasing Commons

[Karl Pauls <ka...@gmail.com>]

On 7/24/07, Carsten Ziegeler <cz...@apache.org> wrote:
> Hi,
>
> I updated our commons project, main changes are:
> - parent pom is now in "pom" (similar to our root pom)
> - convenience pom under /commons to build the whole tree
> - Only released artifacts are used (maven-bundle-plugin:1.0.0,
> root-pom:1.0.0)
> - information for the mvn release/gpg plugin to use mvn for release
>   (If this works out, we can add this info to the felix root pom later
> on - adding it now would require to re-release the root pom in order to
> be able to release the commons pom)
> - changed the artifactid for the commons pom from "build" to
> "commons-build" (more unique name)
> - all versions are 1.0.0-SNAPSHOT
>
> With these changes I would like to release the commons parent pom,
> followed by the bundles and then call a vote on all these artifacts.

I have to admit that I didn't follow the progress of commons that
closely (so it's great that we see progress again!). I do remember
however that there was some concern about the idea some while back
about the problem that some of the wrapped projects might not work
properly in an OSGi environment. So I guess my overall question in
regard to releasing commons is, have you actually tried all of the
resulting artifacts and think they do what they are supposed to do (or
somebody else)?

regards,

Karl

> If noone objects (lazy consensus...) I'll go ahead in the next days.
>
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
>


-- 
Karl Pauls
karlpauls@gmail.com