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

[Mark Little <mlittle@xxxxxxxxxx>]

+1

Unfortunately I'm swamped this week due to Red Hat Summit but will try
to reply asap or next week at the latest about the process we've come
up with in Eclipse MicroProfile and tried to define a tree-like
structure for how "specs" could evolve. Perhaps Kevin or one of the
other MicroProfile members could summarise that earlier than me but
it's doesn't sound too far from what you've presented, Bill.

Mark.


On Mon, May 7, 2018 at 6:53 AM, Kevin Sutter <sutter@xxxxxxxxxx> wrote:
> 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=
>
>
> _______________________________________________
> 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
>