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

["Kevin Sutter" <sutter@xxxxxxxxxx>]

Thanks, Bill.

I agree that Eclipse should drive and
chair this meeting.  Whether it's Mike or Paul, I don't care.  But,
like you said, Eclipse will own this process at the end of the day.  They
have also been most closely involved with Oracle on the licensing aspects
-- which will eventually come into play.

I think you summarized the discussions
on profiles very nicely in your last paragraph.  +1

> Finally, I agree that the intent should be to
define a collection of
> specs that integrate to form a coherent platform.  Still, there's
> value in being able to use many of the specs independently. 
There 
> doesn't need to be a name for each interesting collection of specs. 
> If the implementations of the specs all come from a single vendor's
> Jakarta EE product, then you know that you're still writing a 
> Jakarta EE application even if you only use a few of the specs. 
You
> can choose just the specs you need, adding or subtracting based on
> your application requirements.  If the implementations of the
specs 
> come from multiple vendors and you're assembling them yourself, 
> that's fine, but that's not Jakarta EE and there doesn't have to be
> a name for the collection you assembled.  And it's up to you
to make
> sure they work together.


---------------------------------------------------
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

jakarta.ee-spec.committee-bounces@xxxxxxxxxxx wrote
on 05/04/2018 03:09:50 PM:

> From: Bill Shannon <bill.shannon@xxxxxxxxxx>
> To: jakarta.ee-spec.committee@xxxxxxxxxxx
> Date: 05/04/2018 03:13 PM
> Subject: [jakarta.ee-spec.committee] process,
platforms, profiles, etc.
> Sent by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
> 
> First, thanks to David for trying to pull me into the discussion. 
> Sadly, it was too early in the morning for me to have the lightning-
> fast reflexes needed to unmute and interrupt the discussion before
> someone else jumped in.  But that's ok because many of you made
the 
> same points I would've made.
> 
> Next, it wasn't clear to me whether this was formally done so I'd
> like to nominate Mike as the chairperson for this group and the 
> leader of these meetings.  Eclipse needs to own and manage the
> process we're defining so Mike seems like the right person to lead
this group.
> 
> 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.
> 
> Diving into the profile issue a bit, let me provide some background
> on the Web Profile and my opinion on what we should do going forward...
> 
> The Web Profile was primarily a response to the complaints we heard
> from developers that Java EE is too big and heavyweight.  (I've
> never fully understood why Java SE isn't also too big and 
> heavyweight given that it's much larger than Java EE, but so be 
> it.)  The Web Profile allowed Java EE to compete more directly
with 
> "roll your own" solutions based on (e.g.) Tomcat.
> 
> Secondarily, the Web Profile allowed additional vendors to enter the
> Java EE ecosystem by lowering the barriers to entry.  Given the
> consolidation we were seeing in the Java EE vendor space it seemed
> important to enable new vendors to enter this space, thus 
> encouraging competition in this space.
> 
> This all made sense in the Java EE 6 timeframe.  Since then,
my 
> thinking has evolved.  With the introduction, finally, of a module
> system in Java SE, it makes more sense to me to address the 
> complaints of Java EE / Jakarta EE being "heavyweight" by
dividing 
> the platform into modules and allowing users to choose the modules
> they need for their application.  A vendor would be required
to 
> provide the complete set of modules defined by a platform, but a 
> user of the vendor's product would consider the product more of a
> box of "Lego" bricks from which many different runtimes
could be 
> assembled.  Several others said the same thing in the meeting
and in
> the separate jakarta.ee-community thread.
> 
> Profiles define what vendors must provide and thus what things the
> brand can be associated with.  If there's a different profile
for 
> the different collection of things each vendor wants to provide, 
> then you've destroyed any value in the platform.  Three profiles
is 
> probably fine, five profiles seems like an extreme upper limit. 
And
> I don't think profiles need to be concentric circles.  It was
clear 
> in the discussion that there's no agreement on what a "core"
profile
> would be so I wouldn't even consider that.  Again, profiles are
more
> for vendors than for developers so we need to be clear what 
> additional vendors are being enabled by the definition of additionalprofiles.
> 
> Profiles should be defined by a separate spec.  Defining them
in the
> platform spec means you have to update the platform spec to define
a
> new profile.  That results in gratuitous updates to the platform
> (and corresponding RI and TCK) or the inability to define a profile
> based on existing component specs.  And while it might not be
a 
> requirement, it seems perfectly reasonable for there to be a profile
> TCK that tests the interactions between specs.
> 
> Finally, I agree that the intent should be to define a collection
of
> specs that integrate to form a coherent platform.  Still, there's
> value in being able to use many of the specs independently. 
There 
> doesn't need to be a name for each interesting collection of specs. 
> If the implementations of the specs all come from a single vendor's
> Jakarta EE product, then you know that you're still writing a 
> Jakarta EE application even if you only use a few of the specs. 
You
> can choose just the specs you need, adding or subtracting based on
> your application requirements.  If the implementations of the
specs 
> come from multiple vendors and you're assembling them yourself, 
> that's fine, but that's not Jakarta EE and there doesn't have to be
> a name for the collection you assembled.  And it's up to you
to make
> sure they work together.
> 
> Looking forward to a pointer to Mike's document so I can provide 
> more direct feedback on it...
> _______________________________________________
> 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://urldefense.proofpoint.com/v2/url?
> u=https-3A__dev.eclipse.org_mailman_listinfo_jakarta.ee-2Dspec.committee&d=DwICAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=Qls2GqHdWuE9I7Kaz9VMvnGzdAsbURuCOmbXtD5fj3E&s=JWex1-0pI89ocfKu-
> _f8tHCMBaFWcnm81PJb1-sqfqA&e=