Re: [ee4j-community] Charter Feedback

["Kevin Sutter" <sutter@xxxxxxxxxx>]

The clarification that I would like to
make is the Top-Level Charter for EE4J is not a replacement for the Java
EE "platform specs".  I would expect the Java EE Platform
spec (and Web Profile spec) to move over to EE4J as a separate Eclipse
project (under the EE4J umbrella).  The evolution of this new "platform
spec" could discuss additional profiles and/or modules.  We have
to remember that the establishment of EE4J and the associated projects
needs to be on par with Java EE 8 initially.  After these projects
are established and shown to be consistent with Java EE 8, then updates
can be entertained for future revisions.

---------------------------------------------------
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/07/2017
12:56:52 PM:

> From: Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>
> To: ee4j-community@xxxxxxxxxxx
> Date: 10/07/2017 12:57 PM
> Subject: Re: [ee4j-community] Charter Feedback
> Sent by: ee4j-community-bounces@xxxxxxxxxxx
> 
> Josh, Reza,
> 
> I think everyone can agree that profiles are a powerful concept, and
> that not only do we want to continue to use them, we want to make
it
> easier to add more.
> 
> That said, I can explain why profiles were omitted from the Eclipse
> EE4J charter. Profiles are a standardization thought, not an open
> source project concept. So the thinking is that if some group wants
> to specify a profile they would do that via the to-be-determined 
> specification process, not via EE4J. 
> 
> Happy to be told that it is a dumb reason though :)
> 
> P.S. A modular platform is a great idea, and I hope that is the 
> direction this goes in. But that would ultimately be a technical 
> decision made by the PMC. I don't think we're in a position to 
> mandate that at this point. 
> 
> On 2017-10-07 12:29 PM, reza_rahman wrote:
> I too agree profiles are a very valuable concept
and goes extremely 
> well with the notion of ground-up modularity. Perhaps there is a way
> to mention both concepts together in the charter?
> 
> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
> 
> -------- Original message --------
> From: Josh Juneau <juneau001@xxxxxxxxx>
> Date: 10/7/17 10:25 AM (GMT-05:00) 
> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
> Subject: Re: [ee4j-community] Charter Feedback
> 
> I agree with all comments made in this discussion...+1.  
> 
> I am a little surprised that the project charter does not reference
> the development and/or support of multiple EE4J profiles, such as
> Java EE has today.  At this time, one has the opportunity to
choose 
> between using the Java EE web profile or the full umbrella for a 
> project.  Vendors and cloud/microservices implementations also
can 
> be Java EE compliant with one or both of these profiles.  I hope
> that EE4J will adopt similar profile model, carrying forward what
is
> available in Java EE and even building upon it.  I had always
hoped 
> that Java EE would branch out into even more profiles, specifically
> having one that was geared towards cloud/microservices, such as 
> MicroProfile.  Maybe the idea of profiles goes away and EE4J
just 
> becomes a modular platform, allowing one to utilize any 
> specifications that are required for their application?  
> 
> Just thought it may be helpful to have a bullet point around 
> multiple profiles somewhere in the charter.
> 
> Thanks
> 
> Josh Juneau
> juneau001@xxxxxxxxx
> http://jj-blogger.blogspot.com
> https://www.apress.com/index.php/author/author/view/id/1866

> 
> On Sat, Oct 7, 2017 at 7:14 AM, Ondrej Mihályi <ondrej.mihalyi@xxxxxxxxx
> > wrote:
> Good points, Reza and John. 
> 
> Most important points I agree with:
> 
>  - using application runtimes instead of application servers
>              
      - it's a more flexible term and many Java EE 
> implementations aren't traditional servers anymore
>  - cloud-native or cloud-ready instead of
just microservices
>              
      - at some point we'll need to address serverless
> and FAAS and I believe Java EE has a potential to be used there too
>  - target on both standalone, in-container
and later possibly FAAS 
> environments
>              
      - CDI 2.0 already does that, with a core spec 
> and additions for Java SE and EE and it's brilliant and easy
to follow
>              
      - Java SE version shouldn't, however, contain 
> anything that can be provided by another API from the umbrella, for
> example, it shouldn't provide its own DI mechanism if it's provided
> by CDI, or at most a very simplistic one based on Java SE or EE standards
> 
> --Ondro
> 
> 2017-10-07 7:24 GMT+02:00 John Clingan <jclingan@xxxxxxxxxx>:
> Reza, good points. Comments below. 
> 
> On Oct 3, 2017, at 6:19 PM, Martijn Verburg <martijnverburg@xxxxxxxxx>
wrote:
> 
> Hi Reza, 
> 
> My 2c on this
> 
> On 3 October 2017 at 18:04, <reza_rahman@xxxxxxxxx> wrote:
> As promised, I went through the charter in detail
and have the 
> feedback below. Items are roughly in priority order. I will try to
> encourage others to also provide feedback. Please let me know if it
> is best to split up into separate threads. Please also let me know
> if anything needs further clarification. I really hope this helps.
> * The charter fairly clearly targets application
servers. Personally
> I certainly value the application server model. However, I think at
> this point it is clear developers also value being able to utilize
> the Java EE programming model in embeddable, modular, compose-able
> run-times (aka fat jars). I think it is best to remove references
to
> application servers and simply say something like run-times for
> server-side Java applications. I think the reality is that most EE4J
> implementations will support both models. I can even see 
> implementations that provide no support for the application server
> deployment model.
> Completely agree, there are perhaps even APIs
/ Specs that we 
> develop which would run serverless so to speak. 
> 
> Thanks for bringing this up in the “Opening Up Java EE” panel as
> well. Everyone agreed with this during the session.
> * I think it is important to point out that most
of the time (of not
> all of the time) APIs and technologies under the EE4J umbrella are
> expected to run standalone in Java SE environments. This is one of
> the continuing source of criticism for the current Java EE model.
> While most Java EE APIs are essentially standalone, the platform 
> specification text says nothing about this. In the same vein, I 
> think it is wise to make some reference to modularity even in 
> integrated run-times.
> 
>  I do like “standalone on Java SE" as a "guiding principle”.
It will
> facilitate broad adoption of EE4J technologies, not to mention other
> pragmatic reasons (easier testing, etc).
> * I see references to micro-services, which is
good. I think we 
> should also make a point to reference the cloud. While it is 
> implicitly understood that server-side can mean the cloud, I think
> specifically mentioning the cloud in the charter has value. I can
> envision run-times that are completely cloud native (e.g. Functions
> as a Service) that do not support the on-premises model at all. It
> may actually be handy to have cloud native in the text somewhere.
> 
> I prefer we simply replace “microservices” with “cloud native”,
> which is a broader, more abstract conceptual description that 
> encompasses both FaaS and microservices. Oddly, “server side” is
> more broad that “cloud native”, and encompasses both traditional
on-
> premise and cloud native architectures :-) However, I agree that 
> referring to the cloud is a good balance.
> 
> Good call - the ecosystem at large needs to know that Java can be
a 
> cloud native platform, EE4J could make a strong statement here. 
> * I think its smart to say *modern* server-side
Java applications 
> instead of just server-side Java applications.
> 
> +1
> 
> The definition of “Modern" changes on a monthly basis - by 
> definition. Adding this future-proofs EE4J! :-) I actually think 
> that using “cloud native” as discussed above covers this point.
> 
>  
> _______________________________________________
> 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=TJBuJcgXKbxG9xpap7u2fR8zKw7hhL76fqqb5q_xr0k&s=RK-
> RF2PB3TBLzVWrs4CneAH6y2tsOvo4MC0QYTjnuuE&e=