incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
Date Fri, 04 Sep 2009 11:21:20 GMT
On Fri, Sep 4, 2009 at 07:50, Niclas Hedhman <niclas@hedhman.org> wrote:

> On Fri, Sep 4, 2009 at 1:23 PM, Kevan Miller<kevan.miller@gmail.com>
> wrote:
>
> > So, let's assume that one or more OSGi spec implementations are a core
> part
> > of Aries -- with specific features/customization for Aries. Personally,
> it
> > seems reasonable that an Aries project would want these customized spec
> > implementations close at hand -- within their project.
>
> I would like to draw attention to "Pax Web", which is both a OSGi Http
> Service implementation as well as many extensions, such as war, jsp,
> filter support. Yet it is done in a way of a custom extension
> mechanism (Pax Web Extender), so that if you only use Pax Web, you
> only get the basic spec implementation, nothing more, nothing less. I
> am sure a similar approach could be made here, where the clean spec
> part is at one place and the customizations are "close at hand".
>

My real problem is not the location, but really the fact that we'd split
things.
Do you really see how easy it would be if pax-web was developed at apache
and pax-web-extender in ops4j ?
The two are somewhat tied together, and the value for having pax-web
somewhere else is much lessened by the problems it would bring (it would be
much more difficult to keep both in sync, meaning the communities have to be
roughly the same, and what about the release process which would be much
more difficult too).

For Aries, I would see the same problem.  That might be even worse given
some of the things that are supposed to be done don't exist yet.   So when
you have an existing code base, you can envision splitting it into two when
it's mature enough.   Another thing, is that some things are not yet OSGi
spec, but might become so in the future (such as application metadata and
such), so it might be difficult to choose a destination right now.  For
blueprint, some aspects are not yet standardized (such as custom
namespaces), so they are tightly bound to the implementation.   I don't
think it would make much sense to split that either.

Let's try to find a solution to this problem.


>
> > What would be the
> > benefit for the Aries community of developing these spec implementations
> at
> > Felix?
>
> Ideally, you have more people taking care of any issues. More
> importantly, you need to think outside the project and ask "What would
> be the benefit for ASF...?", and IMHO having a complete spec suite
> from one place benefits ASF as a whole.
>
> >> The only conclusions I see being drawn by people who have invested very
> >> little in Felix is that we should dismantle the Felix charter so that we
> can
> >> accommodate the fact that some people don't want to play with us.
> >
> > I don't know why anybody would want to "dismantle the Felix charter". I'm
> > not sure why Aries would impact that one way or another...
>
> Richard is over-reacting, and statements like that should be left for
> it is; an attempt to blow things out of proportion to gain sympathy,
> possibly out of frustration.
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://www.qi4j.org - New Energy for Java
>
> I  live here; http://tinyurl.com/2qq9er
> I  work here; http://tinyurl.com/2ymelc
> I relax here; http://tinyurl.com/2cgsug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message