A goal of Aries is to seed a new community focused on the development of an Enterprise Java OSGi application programming model, and runtime that is agnostic of server runtime or OSGi framework implementation. This independence from underlying technology will make Aries' appeal as broad as possible - to Enterprise Java consumers of Equinox's spec implementations and Felix's spec implementations, alike. Keeping the two concerns of application programming model and JEE/OSGi integration together in the same project is (IMHO) sensible considering the dependence of one on the other and therefore the likelihood of one influencing the other. In addition our initial contribution has been developed by people working on both concerns.
The fact that some of the JEE/OSGi integration has already been brought to OSGi shouldn't mean an implementation (in our contribution) needs to be hosted under a different TLP. While Felix has a charter to "create software implementing the OSGi Service Platform", does this preclude another project from overlapping with that charter? I didn't think so. Also, I think in this case it makes sense as the EEG specifications mentioned don't have implementations in Felix and they are tightly related to the Aries goal of creating an Enterprise Java OSGi application programming model. Much of the discussion as to where Aries code (including initial contribution) resides would seem to be a decision we should take at graduation rather than before incubation starts. I would like to see us build a single community around Enterprise Java OSGi application programming model in one place (in the incubator) and see where that takes us. (But of course I would say that). Jeremy 2009/9/2 Karl Pauls <karlpa...@gmail.com>: > From my perspective, the incubator isn't a loophole around the > meritocracy approach of existing TLPs. Submitting a couple of patches > can't be to high a barrier for people new to the ASF and the code > base. > > We regularly vote people in as committers if they contribute to felix > subprojects and typically, if we accept a larger piece of code as a > donation, we try to get the creator as a committer too. We did this > with Karaf recently. > > I think felix is an excellent place for consolidating OSGi > spec-related development here at Apache since the community is in > place and very active. > > regards, > > Karl > > On Wed, Sep 2, 2009 at 5:29 PM, Guillaume Nodet<gno...@gmail.com> wrote: >> We have in this proposal a lot of people who are not felix committers and >> who are not even apache committers at all. >> >> They want to work on some code and create a community around it. The way >> the ASF works means that the incubator is the right place to do so. The >> only other solution is to develop it in a closed source environment and >> submit it at Apache when it's done, and i really don't think it's a good >> idea, given the willingness to do it in open source. >> The blueprint implementation has been developped so far inside the Geronimo >> TLP, part of the reason is that some of the people working on it were not >> felix committers, so it was way easier to work there instead of contributing >> patches until getting committership. It is very difficult to commit to >> work on a new implementation of anything when you don't even have commit >> priviledges. It's ok for patches, but not for a new dev. That's what we >> have here. We have people here wanting to work on some new OSGi spec >> implementation, and the only way for them to do so at Apache in to go into >> the incubator. >> >> Even, if Aries was to compete against Felix in any way, it's not a good >> enough argument. We already have multiple projects in the ASF that do have >> overlap as it was pointed already multiple times in this thread: mutliple >> REST implementations, multiple JAX-WS implementations, etc... But the Aries >> podling does not aim to even provide alternative implementation to what >> Felix already has, it's goal is to create a community with new people who >> want to work on that and deliver both implementations of new OSGi specs >> (such as blueprint and subsystems / applications, jpa ...) and also >> additional extensions (such as blueprint custom namespaces for transactions, >> etc...). >> >> For the independance, the only real place I know which provides OSGi >> components, not tainted with a given framework are SpringSource (though it's >> open source, the community is not really open) and OPS4J, but I do think >> it's a different discussion. >> >> I restate that the goal of the Aries proposal is to foster a community >> around some new code implementing some OSGi specs. And I don't think we can >> do that inside an existing TLP, as we have non apache committers that want >> to create this code. That's what the incubator has been created for. >> >> Last, accepting to create a podling does not mean the final destination of >> the podling is defined yet. Aries could become either a TLP, a Felix >> subproject, or be split across the two of them. The one that makes the most >> sense should prevail at graduation time. By the time Aries is ready to >> graduate, the discussion about it's final destination will be held. And >> that's where what you say will make sense and where your vote needs to be >> cast. >> >> I really do understand your concerns (even if I don't share them), but now >> is not the time to vote -1. >> >> On Wed, Sep 2, 2009 at 16:30, Richard S. Hall <he...@ungoverned.org> wrote: >> >>> I will try to keep this short. >>> >>> The OSGi Service Platform is composed of the core and compendium specs. The >>> EEG specs are not in any way special and will ultimately end up as part of >>> the compendium spec. Apache Felix was incubated to build a community at >>> Apache around implementing the OSGi specs. >>> >>> Now we are being told that this mission is too tainted because we implement >>> the framework spec, which is part of the core spec. I find this unfathomable >>> given the nature of OSGi and the efforts to which the Felix community goes >>> to be good OSGi citizens...we even allow for competing implementations >>> within our community. >>> >>> It is also particularly odd, since the Equinox and Knopflerfish communities >>> are in the same situation, implementing both core and compendium specs with >>> their frameworks largely synonymous with their project name. >>> >>> I am not naive enough to expect this discussion to change much, since I >>> imagine there has already been a fair amount of political calculation around >>> this proposal, otherwise the Felix community in general would have been >>> engaged earlier. >>> >>> So, here's my vote: >>> >>> * -1 for the portion of the proposal creating yet another community >>> for implementing OSGi specs at Apache since the Felix community >>> would happily welcome more contribution (just like recently >>> occurred with ServiceMix members being accepted as Felix >>> committers and PMC members for the Karaf subproject) >>> * +1 for the rest of the proposal to explore how to build an >>> enterprise component model on OSGi and the other non-spec related >>> topics. >>> >>> -> richard >>> >>> >>> >>> On 9/1/09 22:53, Kevan Miller wrote: >>> >>>> >>>> On Sep 1, 2009, at 2:08 PM, Richard S. Hall wrote: >>>> >>>> On 9/1/09 13:59, Martin Cooper wrote: >>>>> >>>>>> On Tue, Sep 1, 2009 at 10:51 AM, Richard S. Hall<he...@ungoverned.org> >>>>>> wrote: >>>>>> >>>>>> I'm not sure I understand the issue here. Whether Aries becomes its >>>>>> own TLP, or a sub-project of Felix or some other TLP, isn't relevant >>>>>> until the project is ready to exit incubation. Why does it warrant >>>>>> such apparently intense discussion before the project is even accepted >>>>>> >>>>>> >>>>> We are actually discussing something else. We are discussing the scope of >>>>> the proposal, which includes hosting OSGi standard service >>>>> implementations, >>>>> which is part of Felix' scope. >>>>> >>>>> If we are developing standard OSGi services within Apache, then Felix >>>>> provides an enthusiastic community to do this and there is no need to >>>>> start >>>>> another incubator project for such a purpose. On the other hand, stuff >>>>> like >>>>> "a set of pluggable Java components enabling an enterprise OSGi >>>>> application >>>>> programming model" makes perfect sense to be incubated. >>>>> >>>> >>>> Thanks for the clarification... So, your issue is mainly with "It is a >>>> goal of the Aries project to provide a natural home for open source >>>> implementations of current and future OSGi EEG specifications..."? >>>> Personally, I tend to think of Felix in terms of OSGi Core Platform. I >>>> certainly hadn't expected it to be the source for all OSGi standard >>>> implementations from Apache -- not for implementations of Enterprise Expert >>>> Group specs, anyway. I'm sure there are flaws with my perceptions... >>>> >>>> So, we have a group that is interested in working on an enterprise OSGi >>>> application programming model at Apache (including implementations of at >>>> least some EEG specifications). An incubator project would seem to be an >>>> excellent place for this work to start. Interested Felix community members >>>> would certainly be able to join this effort. >>>> >>>> It then becomes a question of, assuming successful incubation, where does >>>> the community graduate to? TLP, Felix subproject(s), or elsewhere. All >>>> successful outcomes, IMO. >>>> >>>> --kevan >>>> >>>> --------------------------------------------------------------------- >>>> 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 >> > > > > -- > Karl Pauls > karlpa...@gmail.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
