+1
Ondro,Excellent observations. I am especially
keen on MicroProfile not losing it's autonomy. I'd like to see MicroProfile
to continue as the innovative arm of Jakarta EE. And, as the MP technologies
mature and become well-defined, then entertain their inclusion in the Jakarta
EE platform. But, to say that all of MicroProfile has to be integrated
into the Jakarta EE platform -- I'm not there yet.
---------------------------------------------------
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/kevinwsutterFrom:
Mark Little <mlittle@xxxxxxxxxx>To:
Jakarta EE community
discussions <jakarta.ee-community@xxxxxxxxxxx>Date:
05/22/2018 04:58 AMSubject:
Re: [jakarta.ee-community]
About ProfilesSent by:
jakarta.ee-community-bounces@xxxxxxxxxxx
+1On 22 May 2018, at 10:56, Ondrej Mihályi <ondrej.mihalyi@xxxxxxxxxxx>
wrote:I agree, simple and clear process of defining
profiles is very important. I also suggest separating the profiles
into different specifications so that they can evolve separately, with
different release schedule. I would love to see Jakarta EE as an umbrella
for multiple separate profiles, evolving at their own pace but sharing
the same infrastructure, brand and vision. This would, for example, allow MicroProfile
to become one of these profiles, without losing its autonomy. It would
also allow creating a separate IoT profile which would be free to add specs
only relevant to IoT. Another example would be a Reactive profile designed
for reactive systems.Creating profiles for specific use cases
makes a lot more sense to me then just slicing down the Full Profile to
generic profiles like the existing Web Profile or the discussed potential
Core profile. Cheers,Ondrej MihályiSenior Payara Service Engineer
Payara Server – Robust.
Reliable. Supported.
E: ondrej.mihalyi@xxxxxxxxxxx| T: +1 415 523 0175 | M: +421 902 079 891----------------------------------------------------------------------------------------------------------------------Payara Services Limited, Registered office:
Unit 11, Malvern Hills Science Park, Geraldine Road, Malvern, WR14 3SZ
Registered in England and Wales: 09998946 | www.payara.fish| info@xxxxxxxxxxx| @Payara_Fish
From: jakarta.ee-community-bounces@xxxxxxxxxxx<jakarta.ee-community-bounces@xxxxxxxxxxx>
on behalf of Mark Little <mlittle@xxxxxxxxxx>
Sent: 22 May 2018 11:44:50
To: Jakarta EE community discussions
Subject: Re: [jakarta.ee-community] About Profiles Whatever we do, as I mentioned below
too, we should define some relatively straightforward process to define
and agree new profiles in case new use cases come up and don’t fit the
current profiles.Mark.On 21 May 2018, at 10:48, Adam Bien <abien@xxxxxxxxxxxxx>
wrote:Hi Mark,
absolutely. We should wait with the introduction of new profiles until
we get some good use cases and also sound names for the profiles.#
cheers,
adam
On 16. May 2018, at 11:43, Mark Little
<mlittle@xxxxxxxxxx>
wrote:
Profiles should be use case driven. Maybe today we only have use cases
that could define a couple or three profiles and that’s perhaps good enough.
But in 12 months time who knows? Therefore, one other thing we should consider
is a process by which additional profiles can be defined and then agreed.
Let’s not lock this down so that in a few years time a few vendors decide
they have no choice but to go off and do something different again ;)
Mark.
On 7 May 2018, at 17:47, Kevin Sutter
<sutter@xxxxxxxxxx>
wrote:
I think defining one or maybe two profiles (in addition to full platform)
would satisfy most of the discussion points in this thread. It would
allow vendors to comply with a couple of pre-defined subsets of the full
platform without requiring them to list all of the individual specs. And,
at the same time, it would allow these vendors to also specify what additions
they provide beyond the given profile. For example, a vendor could
claim compliance for Web Profile (as currently defined by Java EE) and
full EJB 3.2 support. (If the full EJB 3.2 spec had a standalone
TCK, of course.)
---------------------------------------------------
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
From: arjan tijms <arjan.tijms@xxxxxxxxx>
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Date: 05/07/2018 11:33 AM
Subject: Re: [jakarta.ee-community] About Profiles
Sent by: jakarta.ee-community-bounces@xxxxxxxxxxx
Hi,
On Mon, May 7, 2018 at 5:05 PM, Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx>
wrote:
Here is the problem with not having a profile. If there is no profiles
than every vendor (including OSS) has to implement the entire platform
in order to be compliant.
So then the first question is perhaps; who wants profiles and benefits
from it? Is a profile intended for vendors or for users?
The second question, which vendor actually full implements the entire platform
itself now? Even IBM (arguably the biggest vendor) bundles various component
jars instead of developing everything from scratch.
I can’t just implement what I want and still claim Jakarata EE compliance.
But isn't that the entire idea of compliance? If you just implement whatever
you want, how can that even be compliant with anything?
Has there ever been a discussion about this regarding say the C++ std lib?
I.e. someone only wants to implement c:out, and then still claiming C++
compliance? What does it even mean then? (I know this example is taken
to the extreme, but it's just an example).
I have to implement the full platform and all of its APIs.
As mentioned above, I don't think you have to. Most APIs can just be taken
from open source and bundled.
That’s too much to ask of many vendors and is why there was consolidation
of vendors in Java EE. Instead, Profiles allow vendors to achieve
compliance with a standardized subset, a Profile, as an option rather than
entire platform. A vendor can choose to be certified for the entire
platform or a profile.
I'm not sure if a bloated product line-up with a dozen profiles really
makes things easier for users.
Say I have an application that's written against Jakarta EE profile 23.
Will it run against Jakarta EE profile 14? If vendor 56 supports profiles
4, 7, 16 and 21, can I run an app for that also on vendor 33's product
which supports profiles 3, 8, 9 and 12?
Kind regards,
Arjan
On Mon, May 7, 2018 at 8:58 AM arjan tijms <arjan.tijms@xxxxxxxxx>
wrote:
Hi,
After some thinking about it as well, I feel we really don't need many
profiles at all.
Just the full profile should be enough, and a legacy free profile that
excludes the stuff nobody wants to implement just for compliance (such
as EJB CMP), and which can slice within specs as well (ala EJB-lite, to
remove packages, classes, or methods within classes).
The perfectly suited "individual profile" can then be generated
by users via a tool which prunes all the specs they personally don't need
from a given full or legacy free server. The result of such pruning is
a new server that physically doesn't contain the specs that bother people.
So for instance if people are bothered by the idea that JSF is in their
server, they can run this tool and then the Mojarra jar won't be present
at all in the resulting new server.
Thoughts?
Kind regards,
Arjan
On Mon, May 7, 2018 at 3:45 PM, Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx>
wrote:
After thinking more about this and discussing this with David Blevins I’ve
come to believe that there should be a “includes everything” full profile
which ensures that all component specifications work together with subset
profiles that represent only slices of the full profile.
Some vendors (including OSS) might choose to implement the Full Profile
- the reference implemenation should do this for sure - but many will choose
to implement only a sub-profile (e.g. Web Profile, IoT, REST ). A
vendor can be certified according to a sub-profile and need not implement
the Full Profile. The sub-profiles would be standardized. Any
time a new specification or API is added to Jakarta EE it must first interoperate
with the Full Profile. Once it does it can be included the specification
of any sub-profile.
On Thu, May 3, 2018 at 5:41 PM Ondrej Mihályi <ondrej.mihalyi@xxxxxxxxxxx>
wrote:
My view:
- have a Full profile
- have multiple modules that group several hugely related specs
- modules can be combined
- all modules combined would be equal to the Full profile
Full Profile - the simplicity Adam seeks
Maybe have a legacy-free profile too (without SOAP, remote EJB or even
without EJB if other specs can provide the essential features) -
WebProfile is very close to this
Modules would enable users to take only what they need but wouldn't be
as prominently promoted as the Full/legacy-free profiles.
Each individual spec could be a module - the essential problem with that
is it's hard to test all combinations of specs. So less granular modules
could decrease the number of combinations dramatically while allowing picking
only what's needed.
Cheers,
Ondrej Mihályi
Senior Payara Service Engineer
Payara Server – Robust. Reliable. Supported.
E: ondrej.mihalyi@xxxxxxxxxxx|
T: +1 415 523 0175 | M: +421 902 079 891
----------------------------------------------------------------------------------------------------------------------
Payara Services Limited, Registered office: Unit 11, Malvern Hills Science
Park, Geraldine Road, Malvern, WR14 3SZ
Registered in England and Wales: 09998946 | www.payara.fish|
info@xxxxxxxxxxx|
@Payara_Fish
From: jakarta.ee-community-bounces@xxxxxxxxxxx<jakarta.ee-community-bounces@xxxxxxxxxxx>
on behalf of Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx>
Sent: 03 May 2018 16:15:11
To: Jakarta EE community discussions
Subject: Re: [jakarta.ee-community] About Profiles
+1 . I agree with the Facade argument as well. The CDI is,
in essence, the Facade while the underlying details are defined by the
abstract Core.
On Thu, May 3, 2018 at 9:07 AM Adam Bien <abien@xxxxxxxxxxxxx>
wrote:
On 3. May 2018, at 16:02, Richard Monson-Haefel
<rmonson@xxxxxxxxxxxxx>
wrote:
I understand where Adam in is coming from in terms of simplicity - I have
wrestled with how to accommodate multiple profiles and simplicity as well.
I do not think, however, that supporting multiple profiles makes
for an inherently more complex platform. On the contrary.
I'm coming from projects :-)
The abstract and subclass analogy is good. However, both should be hidden
behind a facade. The developers should only know the facade -> and what
is hidden behind are the implementation details.
I'm absolutely convinced we need a thin main profile. This should be good
enough for majority of use cases.
All other profiles has to be motivated by application types or use cases.
If Jakarta EE can define a Core of absolutely necessary technologies (e.g.
CDI) than profiles, which are, by design, interoperable with the core and
other profiles can be defined and used as needed.
I like to think of the Core as the abstract class (sorry functional purists
but I’m going OO on this analogy) and the profiles as interfaces that
can be optionally implemented by vendors. The vendor implements a concrete
version of the Core, the behavior of which is strictly specified and certified,
and then zero or more of the profiles. When a profile is specified
we ensure that the TCK for that profile requires interoperability with
the Core and if all profiles work as specified with the Core than they
will work together without compatibility issues. For the first time,
we have full control of the specifications and - just as importantly -
the TCKs.
The Core + Profiles approach allows the platform to evolve according to
the needs of the industry instead of according to the needs of any one
problem domain. Right now everyone is saying that SOAP-based web services
are dead so we should ditch that, but in 2004 that opinion would have been
viewed as moronic. What technologies today do we feel are critical
that will be obsolete in 10 years? We don’t know. Profiles
give us the flexibility to support technology and problem domains without
constraining the platform as a whole.
On Thu, May 3, 2018 at 12:06 AM Adam Bien <abien@xxxxxxxxxxxxx>
wrote:
1. From the usability, dev experience, we should aim for as few profiles
as only possible.
My selling point for Java EE in the past was the simplicity. There was
only one choice -- the Full Profile -- (there were no measurable advantages
of WebProfile, so we never used that) what was appreciated by the developers.
There were no unique "snow lake" project in the past what was
good for long term maintenance and corporate developers self support. With
the "one dependency" idea, even startups used Java EE with the
"time to market" advantage. There was no evals or dependency
fiddling. We started with use case implementation at the day one.
2. From the runtime vendor perspective, modular platform is easier to maintain,
develop and is good for the ecosystem. So vendors should modularize the
Java EE platform as far as it is useful. However this should be an internal
implementation detail.
IMO we should have one "main profile" which comprises similar
functionality to the "full profile" in Java EE (of course without
SOAP :-)) which should cover the 80% of the main use cases. This profile
could be implemented as a BOM (micropofile does that, what is really convenient
to use).
Exceptional usecases (e.g. scenarios like NetFlix with 10k of microservice
instances) could be covered by specific profiles.
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
--
Richard Monson-Haefel
http://twitter.com/rmonson
http://www.tomitribe.com
http://www.tomitribe.io
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
--
Richard Monson-Haefel
http://twitter.com/rmonson
http://www.tomitribe.com
http://www.tomitribe.io
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
--
Richard Monson-Haefel
http://twitter.com/rmonson
http://www.tomitribe.com
http://www.tomitribe.io
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
--
Richard Monson-Haefel
http://twitter.com/rmonson
http://www.tomitribe.com
http://www.tomitribe.io
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
---
Mark Little
mlittle@xxxxxxxxxx
JBoss, by Red Hat
Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale
Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell
Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill,
Keith Phelan, Matt Parson (USA)
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community---Mark Littlemlittle@xxxxxxxxxxJBoss, by Red HatRegistered Address: Red Hat Ltd, 6700
Cork Airport Business Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell
Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill,
Keith Phelan, Matt Parson (USA)_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community---Mark Littlemlittle@xxxxxxxxxxJBoss, by Red HatRegistered Address: Red Hat Ltd, 6700 Cork Airport Business
Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell
Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill,
Keith Phelan, Matt Parson (USA)_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________ jakarta.ee-community mailing list jakarta.ee-community@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
--- Mark Little
JBoss, by Red Hat Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)
|
