incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Pauls <karlpa...@gmail.com>
Subject Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
Date Fri, 04 Sep 2009 19:49:42 GMT
On Fri, Sep 4, 2009 at 3:53 PM, Daniel Kulp<dkulp@apache.org> wrote:
> On Fri September 4 2009 9:27:23 am Graham Charters wrote:
>> Having read all the discussions, I still have concerns about the
>> suggestion to put all OSGi spec implementation under Felix.  I don't
>> see this approach being taken for other specification organizations
>> (JCP, OASIS, etc.) and I think that is to the benefit of Apache.  For
>> example, whilst a goal of Geronimo is JEE compliance it does not host
>> all the implementations of the JEE specifications.  Having OpenEJB,
>> OpenJPA, Tomcat, etc as separate projects allows them to evolve
>> independent communities, with cross-pollination.  The domains,
>> technologies and skills required to cover the entirety of JEE are
>> diverse and the same is true for OSGi.  To put these under one project
>> would lead to sub-groups of different interests under one disjoint
>> umbrella community.
>
> +1
>
> Geronimo is a perfect example.   Couldn't have said it better myself.   The
> community of the "experts" in the technology area should be the ones
> implementing those specs as part of their community.

Um, for me it is a perfect example for the opposite :-)

Geronimo is using the artifacts of other communities to create
something that is bigger than the sum of its parts. The parts in turn
are developed not within geronimo but (as you say yourself) by the
respective communities that are the "experts". For me this is a
perfect example of what we propose in this discussion. Let us develop
(and build the "expert" community around) the OSGi EE spec related
components at Felix and let Aries be the project that makes use of
them to create something that is bigger than the sum of its parts
namely, to explore how to build an enterprise component model on OSGi
and the other non-spec related topics.

regards,

Karl

> Dan
>>
>> I also worry about the practicalities of saying that all OSGi spec
>> implementations belong in Felix.  This is a moving target, both within
>> each specification, where extensions may be created and then
>> standardized and also at the spec level, where new concepts are
>> created and then standardized.  Must these then move under the Felix
>> umbrella, which will undoubtedly create a lot of churn for users of,
>> and contributors to, Aries?
>>
>> Thinking about the problem the way JEE is handled makes me wonder if
>> Felix could pull in spec implementations from Aries (and have
>> committers on Aries) and therefore still contribute to and provide the
>> distribution of the entire OSGi Service Platform.  Maybe this could be
>> done through Felix hosting a bundle repository (Felix commons?)?
>> Consumers of Felix would be able to get the OSGi Service Platform and
>> consumers of Aries would get the enterprise OSGi application portions.
>>
>> I'd like to emphasize that the desire to be separate from Felix is in
>> no way a criticism of that project.  I have a huge amount of respect
>> for what Richard et al continue to achieve and having experienced
>> first-hand the value the combination of Felix and Equinox bring to the
>> OSGi standards, I sincerely believe that OSGi is far stronger as a
>> result.
>>
>> The desire to remain separate is based purely on the belief that this
>> is the approach which will best serve the goals of evolving an
>> enterprise OSGi application programming model, and a community around
>> its definition.  This rationale is also the reason why Geronimo was
>> not suggested (an equally valid choice given the majority of the
>> Enterprise OSGi specifications leverage JEE technologies).  I guess
>> what I don't understand is why the Incubator would not prove or
>> disprove this belief, without making a prior decision?
>>
>> Regards, Graham.
>>
>> 2009/9/4 Daniel Kulp <dkulp@apache.org>:
>> > As a point of note, not all OSGi spec implementations live in Felix even
>> > at Apache today.   The Remote Services/Distributed OSGi reference
>> > implementation is a sub project of CXF.     I think Tuscany has an
>> > implementation as well.
>> >
>> > So far, there hasn't been any discussion about moving those into Felix.
>> >  Your argument below makes it sound like they should be.
>> >
>> > Dan
>> >
>> > On Thu September 3 2009 1:33:04 pm Richard S. Hall wrote:
>> >> There was no attempt to contact the Felix PMC in general that I am aware
>> >> and I certainly didn't know about it in advance.
>> >>
>> >> And there seems to be a continued attempt to construe my original
>> >> criticisms as "all of Aries should go into Felix".
>> >>
>> >> I, personally, do not believe that all of Aries should go into Felix, I
>> >> too think it should have its own identity. I was always only ever
>> >> referring to the independent OSGi spec implementations. I was arguing
>> >> that Felix is a good place to work on them, since it is part of what it
>> >> is trying to achieve.
>> >>
>> >> Further, I don't really understand the implication that somehow the
>> >> burden is now on the Felix community to go and contribute to Aries on
>> >> OSGi spec implementations just because of this proposal, when there was
>> >> no attempt to work with the Felix community on creating OSGi spec
>> >> implementations in the first.
>> >>
>> >> 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.
>> >>
>> >> At that rate, I stand by my previous "vote" and otherwise people can do
>> >> whatever they want in Aries.
>> >>
>> >> -> richard
>> >>
>> >> On 9/3/09 13:23, Niclas Hedhman wrote:
>> >> > Kevan,
>> >> >
>> >> > Was a contact with Felix made prior to dropping the proposal here?
I
>> >> > got the impression that wasn't the case, which I find surprising...
If
>> >> > I am wrong, what was the meat of such?
>> >> >
>> >> > I'm also less happy with the rhetoric here repeated over and over,
>> >> > seemingly uninterested in discussion of reaching a solution everyone
>> >> > can accept. (From both camps, btw)
>> >> >
>> >> > -- Niclas
>> >> >
>> >> > On Sep 4, 2009 12:53 AM, "Kevan Miller"<kevan.miller@gmail.com>
>> >> >  wrote:
>> >> >
>> >> > On Sep 3, 2009, at 12:53 AM, Niclas Hedhman wrote:>  On Thu, Sep
3,
>> >> > 2009 at 3:19 AM, William A. Ro...
>> >> > Totally agree. Had certainly hoped that Felix committers would be
>> >> > interested in joining...
>> >> >
>> >> > --kevan
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: gene...
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail: general-help@incubator.apache.org
>> >
>> > --
>> > Daniel Kulp
>> > dkulp@apache.org
>> > http://www.dankulp.com/blog
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: general-help@incubator.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>



-- 
Karl Pauls
karlpauls@gmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message