Re: [ee4j-community] On Naming

["Kevin Sutter" <sutter@xxxxxxxxxx>]

Guillermo,
You are correct.  We are taking
the Config API through the JSR process.  We wanted to demonstrate
the "full cycle" of iterative innovation and then take the result
through the JSR process to establish a standard, which eventually could
possibly feed into Java EE.  The proposal from Oracle to move Java
EE to an open-source foundation threw a little wrench into those plans.
 And, since we don't know how long it will take to be established
in Eclipse, we're going to continue down this JSR path.  If Oracle
would have made this move 6 months earlier, then maybe we would have adjusted
our plans for this Configuration JSR.  But, as it stands, we need
to continue to move forward.  As David Blevins mentioned the other
day in the Java EE Panel, we can't sit on the side lines and wait for the
dust to settle.  We need to work with the new Open Java EE movement,
but at the same time, we need to continue with business-as-usual until
that solidifies.

---------------------------------------------------
Kevin Sutter 
STSM, MicroProfile and Java EE architect
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter

ee4j-community-bounces@xxxxxxxxxxx wrote on 10/01/2017
11:08:51 PM:

> From: Guillermo González de Agüero <z06.guillermo@xxxxxxxxx>
> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
> Date: 10/01/2017 11:09 PM
> Subject: Re: [ee4j-community] On Naming
> Sent by: ee4j-community-bounces@xxxxxxxxxxx
> 
> It's clear that the JCP is a very "heavyweight" process
as it is 
> now, but even MicroProfile has shown interest in feeding JSRs for
> some of their specs (at the moment, only Config).
> 
> I believe we can use a similar approach, doing the heavy lifting 
> here and then moving it to the JCP with Eclipse Foundation as the
spec lead.
> 
> That approach should hardly slow down us or interfere on our processes.
> 
> Regards,
> 
> Guillermo González de Agüero

> On lun., 2 de octubre de 2017 2:06 Mike Milinkovich
<
> mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> 
> Two reasons come to mind:
> There is a strong desire for a lighter-weight,
more nimble process. 

> The IP and process rules around the JCP are complex,
and almost 
> impossible to change. The intent will be to create a new process 
> which provides a level playing field for all of the participants and
> stakeholders. A more open and egalitarian process will hopefully 
> result in more participants and investment in the platform.
> 
> 
> On 2017-10-01 3:52 PM, Michael Nascimento wrote:
> Could you expand on the rationale for that, Mike?
> 
> Regards,
> Michael
> 
> On Sun, Oct 1, 2017 at 11:38 AM, Mike Milinkovich <
> mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> On 2017-10-01 5:15 AM, Guillermo González de
Agüero wrote:
> One question I have on that is wether EE4J could
be used as the 
> OpenJDK equivalent for Java EE and in the same way that MicroProfile
> has just done with MP Config: spec developed on an open group and
> then submitted to the JCP.
> 
> I envision a very similar idea for EE4J: create working groups, 
> develop specs and APIs and then, once done, submit a massive "Java
> EE 9" JSR for it, that will then release the artifacts with the
> "javax" package (this point is *really* important), and
maintaining 
> the Java EE name.
> 
> That leaves the application server certification open though. But
> with all TCKs sources avaiable, I doubt certification by itself will
> be so important as it is now, since everybody will be able to test
> servers on their own to verify they are spec complaint.
> 
> I also imagine major vendors won't like this option that much since
> Oracle would still be responsible of the final "Java EE"
release 
> through the JCP, but I think this can be an acceptable compromise
solution.
> 
> Is this an option that's on the table?

> It is my understanding that the new specification
process will not 
> be using the JCP.
> _______________________________________________
> ee4j-community mailing list
> ee4j-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or 
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/ee4j-community
> _______________________________________________
> ee4j-community mailing list
> ee4j-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or 
> unsubscribe from this list, visit
> https://urldefense.proofpoint.com/v2/url?
> u=https-3A__dev.eclipse.org_mailman_listinfo_ee4j-2Dcommunity&d=DwICAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=c9SXO5t0SqvzWMk1qaUGZCnrwQ4L-
> c8w1SiCQvddm9U&s=Gw7Jq1KI5cve_kwYt5EdTlbkzoikPQOObVIOE8j3sYQ&e=