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