Yes, that's what I intended, modulo the open issue of whether this
new specification process can be used to create specifications that
are not included in Jakarta EE.
Richard Monson-Haefel wrote on 05/ 7/18
07:56 AM:
If I understand this correctly the breakdown
would be as follows:
- A Specification is a collection of packages
possibly arranged in modules. A specification must integrate
with the “Full” platform but can optionally be used
independent of Jakarta EE.
- The “Full” profile or platform includes all
the Jakarta EE specifications. It can be implemented and
certified by a vendor but its not required. A vendor can
choose to implement a standardized sub-set, called a Profile,
of the “Full” platform.
- A Profile is a subset of the “Full” platform
standardized in a profile specification. A Profile contains a
subset of the specifications included in the “Full” profile.
- Any deployment of the “Full” platform or a
Profile can be deployed by developers in Modules so that if a
developers wants to only deploy a portion of the “Full”
platform or Profile they can do so.
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 additional
profiles.
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://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
--
_______________________________________________
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
|
