Re: [jakarta.ee-spec.committee] process, platforms, profiles, etc.

[Mark Little <mlittle@xxxxxxxxxx>]

Agreed and it is a question the JCP EC needs to work on - I raised it
at the Hursley f2f in January and said that we (the EC) need to keep
revisiting it at each meeting until we have an answer.

Note, if the process we come up with here looks, feels and behaves
exactly like the JCP in terms of time to do releases, how quickly
specs can iterate, etc. then I believe we will not be able to
accomplish the kind of changes in rapid innovation we need for Jakarta
EE let alone distance it from the negative perception around Java EE
as a result of things like the previous evolution processes.

Mark.


On Wed, May 9, 2018 at 9:56 AM, Scott Stark <sstark@xxxxxxxxxx> wrote:
> It's not clear that we can be a complete replacement for the JCP since we
> are not getting into Java SE/OpenJDK or Java ME specifications. I do view
> the specification process we are working on as more of a replacement of the
> JCP for enterprise Java related specifications.
>
> There certainly is a question of the purpose of the Java Executive Committee
> with the removal of the Java EE specs, but that is a separate conversation
> in my mind.
>
> On Mon, May 7, 2018 at 6:45 PM, Mike Milinkovich
> <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>>
>> On 2018-05-04 4:09 PM, Bill Shannon wrote:
>> ...
>>
>> I'm still trying to understand whether we're defining a process to replace
>> the JCP, or whether we're defining a process that can and will only be used
>> to define the Jakarta EE platform.  If the former, most of the discussion
>> about profiles belongs elsewhere. And we would need to allow for the
>> possibility that a new spec would be defined but not included in the Jakarta
>> EE platform.  Think of the Portlet and related specs in the JCP; would we
>> want to allow for another ecosystem of specs perhaps related to but not part
>> of Jakarta EE?  Expanding the platform to include every spec ever defined
>> means the platform will grow without bound, placing a significant burden on
>> vendors that ship full platform implementations.  Making every new thing
>> optional means they're not really part of the platform because applications
>> can't depend on them.
>>
>>
>> I had never quite thought of it that way, but from the perspective of the
>> Eclipse Foundation we are defining the former: a spec process to replace the
>> JCP. The initial use case will be Jakarta, but we have already been
>> approached by projects in other areas of Eclipse (e.g. IoT) who are
>> interested in also having a formal spec process. So I believe that this
>> definitely goes beyond Jakarta EE.
>
>
>
> _______________________________________________
> jakarta.ee-spec.committee mailing list
> jakarta.ee-spec.committee@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
>