2009/9/4 Guillaume Nodet <gno...@gmail.com> > On Fri, Sep 4, 2009 at 07:50, Niclas Hedhman <nic...@hedhman.org> wrote: > > > On Fri, Sep 4, 2009 at 1:23 PM, Kevan Miller<kevan.mil...@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 ? >
Well if one module was implementing the defined spec and the other was building on top of it, using some sort of extender approach, then that might work quite well. At least it would be clear what was standard, and what wasn't. 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). > OSGi is supposed to be about introducing modularity, so I would hope that it would be possible for different teams to develop against an agreed / standard API without having too much trouble keeping in sync - once the initial API is defined you can release more or less independently, and let the framework wire things up at deployment time. Both teams would need to agree on how the common API developed over time, but you might actually end up with a better, leaner API that way. Me personally - I would prefer to see the spec implementations hosted at Felix, but if that's not possible then that's ok. Either way I would try to help out where possible (time permitting of course!). But I do think it would be ironic if two OSGi related projects couldn't work together, or even share bundles, because that really would be a bad advert for modularization - let's try to move away from the old approach of silo'd communities and "release trains" and embrace modularity. Then in the end it doesn't really matter where the bundles come from... -- Cheers, Stuart 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-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com >
