I've posted my own summary before and didn't get any feedback, so
re-posting in case it got lost in this thread. Do people agree on
those guidelines related to profiles?
- We need to define "some" profiles for certification and
portability purposes.
- A vendor may claim compliance to one or more profiles
- Specs should have stand alone TCKs so they can be tested
separately and profiles could have additional tests that test
profiles as collections of APIs (profile platform tests).
- Profiles don't necessarily need to inherit from each other,
but they could.
- Within a profile a vendor may package a newer version of a
prescribed spec, if it's compatible.
- Within a profile a vendor may provide additional APIs. This
doesn't change the profile itself.
- Within a profile a vendor may let the user add support for
additional APIs.
- A vendor should have the freedom to offer the user the option
of reducing/optimizing the runtime that implements a particular
profile (which may be also enhanced by the vendor or the user
with additional APIs), for example, by removing API
implementations not in use by a particular app, or creating a
runtime specific for a particular app and link externally to the
deployment or bundle everything together in a fat jar, or
perform any packaging optimization that can improve consumption
in a containerized/cloud environment (e.g. bundle the app, the
runtime and a customized version of the jvm to form an
executable).
- A vendor could offer the user the ability to create their own
custom profiles by starting from scratch, in which case the
resulting configuration is not considered "certified".
Obviously the idea is that profiles provide to the users
different minimum baselines they can enhance and use to build
their apps in a portable fashion, while giving enough space to
Jakarta EE implementors to compete and innovate on features and
performance/deployment optimizations.
As to what the exact profiles should be, if we believe that
backwards compatibility is important, we should provide the
existing
- Java EE Full profile, (Jakarta EE Full Legacy profile?)
- Java EE Web profile, (Jakarta EE Web profile, if still
relevant)
Then for new apps we should be probably looking at new/modern:
- Jakarta EE All profile, with non needed legacy APIs removed
and new ones (possibly) added
- Jakarta EE Micro profile, geared towards microservices
Again, profiles could inherit from each other, but I don't see
that as a requirement, while the proposed names are just
indicative.
Cheers
/Dimitris
Dimitris Andreadis
Engineering Director
Red Hat JBoss EAP/WildFly
On 17/05/2018 15:48, Kevin Sutter
wrote:
+1, Mark. We (IBM) were able to
capitalize
on the defined WebProfile for Java EE 6 for our early WebSphere
Liberty
offerings. Our customers were demanding "Java EE" for Liberty,
but we knew we couldn't deliver the full platform in these early
releases
of Liberty. (Actually, we didn't even know if we *wanted* to
deliver
the full Java EE platform on Liberty at that time...) Having a
defined
WebProfile in Java EE 6 allowed us to satisfy these customer
requirements
in a timely manner. We were able to pass the defined subset of
CTS/TCK
tests for the WebProfile and this defined compliance with the
standard
provided the necessary assurances to our customers that Liberty
was a real
application server.
Since that time, we have decided
that
Liberty should also be compliant with the full platform. But,
that
decision would not cause us to promote a single profile (or
platform) for
Jakarta EE. We need subsets of functionality defined as
profiles
to allow more flexibility for both the developers/vendors
implementing
the technology and the customers that consume the technology.
---------------------------------------------------
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:
Mark Little
<mlittle@xxxxxxxxxx>
To:
Jakarta EE community
discussions <jakarta.ee-community@xxxxxxxxxxx>
Date:
05/17/2018 08:28 AM
Subject:
Re:
[jakarta.ee-community]
About Profiles
Sent by:
jakarta.ee-community-bounces@xxxxxxxxxxx
Dominik, you may feel that my examples are not
valid
but that doesn't
mean they are actually invalid :) The discussions around
profiles date
back many years in the JCP and unfortunately I'm not able to
check at
the moment as to whether those were public. But suffice it to
say we
(Red Hat), IBM, Oracle and many others here, including users,
provided
examples of why profiles were a good thing and necessary based
on many
many years of real world use cases and thousands of customers
asking
for precisely that sort of thing. As I said earlier though,
you are
not alone in only wanting to have the full profile and that's
fine
too. Maybe others, such as Tomitribe who only provide the
WebProfile,
will chime in with some examples of their own but I can tell
you that
since Red Hat implemented both the WebProfile and full profile
in our
community and product app servers we have seen significant
adoption of
both and those developers make the choice based on some of the
reasons
I gave and they clearly understand why and believe their
actions are
valid too :)
Mark.
On Thu, May 17, 2018 at 1:59 PM, Dominik Hufnagel
<mail@xxxxxxxxxxxxxxxxxxx> wrote:
> Well, there certainly are users which are not happy with
just the
full
> profiles and I am sure there are reasons. I do not say
there is no
need for
> more profiles, but until now I have not seen reasons for
it, which
justifies
> it.
>
> For me, your arguments do not justify the complexity for
users having
to
> choose between profiles. If I start a project and having
to make decisions
> on what profile to use, how would that be less expensive
than running
a
> cloud machine with 50MB more for years? Let’s take AWS
for example,
where a
> block storage costs about 0.1-0.2$ per GB per Month.
>
> Regarding boot times, may you/one can specify what fast
means? I have
a
> wildfly app booting in < 10 seconds where a spring
boot app I am
currently
> working on (with almost just REST interfaces) needs >
15 seconds
to boot.
>
>
>
> If you think about the buzzword IoT, then clearly the
full profile
may not
> suit. But I am not sure if this has to be covered under
Jakarta EE.
>
>
>
> I am with you in terms of complexity and portability. For
small
> applications, where mostly one war or app is deployed, it
would be
> beneficial to be able to configure the Application Server
(DB, JMS-Queues,
> …) with any mechanism from inside the war (let’s say a
properties
file or
> something). I would love to see such mechanisms in
Jakarta EE, but
this is
> not really related to profiles.
>
>
>
> I also think it would be beneficial to have a legacy
profile for the
stuff
> that is not anymore ‘state ot the art’, so that the main
profile
could be
> more lean.
>
>
>
> To be clear: I have no final opinion about this topic
yet. I just
like to
> see some valid arguments for having more profiles or for
not have
more
> profiles. What I also did not see in this discussion so
far, are examples
> for profiles and how they fit together. This would help
getting a
clearer
> image of the needs from those who argue for having more
profiles.
>
>
>
> Dominik
>
>
>
> Von: jakarta.ee-community-bounces@xxxxxxxxxxx
> [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx]
Im Auftrag von Mark Little
> Gesendet: Donnerstag, 17. Mai 2018 13:47
>
>
> An: Jakarta EE community discussions
<jakarta.ee-community@xxxxxxxxxxx>
> Betreff: Re: [jakarta.ee-community] About Profiles
>
>
>
> This isn’t just about vendor choice. You are certainly
not alone
in being
> happy with the full profile option. However, there are
other classes
of
> users/developers that aren’t and these have existed since
the dawn
of J2EE.
> For example, some people want to deploy their favour app
server on
to
> constrained devices which may be running on the cloud
where an additional
> 50MB costs real money when run for hours or days or weeks
or longer.
Some
> developers want to reduce the maintenance complexity or
boot time
of their
> favourite app server by stripping out those capabilities
they don’t
want.
> Now you could argue that these developers could just do
this themselves
> anyway, e.g., JBossAS has supported this kind of pruning
from the
start.
> However, if you want portability and interoperability of
your apps
so you’re
> not tied to a specific app server implementation/vendor,
having standardised
> profiles is the right approach.
>
>
>
> Mark.
>
>
>
>
>
> On 16 May 2018, at 23:16, Dominik Hufnagel
<mail@xxxxxxxxxxxxxxxxxxx>
wrote:
>
>
>
> As a user of JavaEE, I do not get the idea behind having
multiple
profiles.
> May someone can explain the benefits for users? If I can
have a single
> profile with all available features, I would take it and
I do not
bother
> using a server which is 50MB larger of one with a
„smaller“ profile.
I can
> understand that it could be harder for vendors to enter
the market
having to
> provide the full profile. But for me, this would not be
an argument
for
> using smaller profiles. I’d rather take a server from a
vendor which
offers
> me the full profile.
>
>
>
> If I would use the MicroProfile and want to have JPA, do
I have to
add
> external dependencies? I really like some of the new APIs
of the
> MicroProfile and would be happy to see them coming to
JakartaEE.
>
> Dominik
>
>
>
>
>
> Von: jakarta.ee-community-bounces@xxxxxxxxxxx
> [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx]
Im Auftrag von Mark Little
> Gesendet: Mittwoch, 16. Mai 2018 11:42
> An: Jakarta EE community discussions
<jakarta.ee-community@xxxxxxxxxxx>
> Betreff: Re: [jakarta.ee-community] About Profiles
>
>
>
> Hopefully others have responded already but … it’s for
both: quick
summary …
> vendors so they can ensure conformance and users so they
can ensure
> portability and interoperability of their apps.
>
>
>
> Speaking with my MicroProfile hat on, I for one would not
want to
trade the
> current MicroProfile for a full Jakarta EE profile and
neither would
our
> users.
>
>
>
> Mark.
>
>
>
>
>
> On 7 May 2018, at 17:33, arjan tijms
<arjan.tijms@xxxxxxxxx>
wrote:
>
>
>
> So then the first question is perhaps; who wants profiles
and benefits
from
> it? Is a profile intended for vendors or for users?
>
>
>
>
>
> ---
>
> 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
>
>
>
> ---
>
> 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
_______________________________________________
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
|