[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakarta.ee-community] Are there no requirements for Innovation?
|
Hi Mihai, All,
Mihai, one can never be late to an open source party! Welcome and thanks for your question. It looks however, I may be late in responding :). Thanks to the community with all the answers so far.
Innovation is core to any open source project, and we certainly encourage innovation in Jakarta EE, particularly through collaboration with other Jakarta EE Working Group members involved in Jakarta EE specification projects.
In terms of requirements for certification of Jakarta EE specification implementations, I will invite you to get familiar with the certification process and compatibility requirements, that will instruct you to join Jakarta EE Work Group and that way enable you to get involved and collectively innovative on the specification projects.
Should you further desire to certify your own implementation, that may be based on Eclipse Glassfish, and have Jakarta EE Compatible Product you need to fulfill certain requirements listed under Jakarta EE Trademark guidelines . I will copy the part you maybe interested the most here:
Use of the “Jakarta EE Compatible” mark is limited to use in conjunction with Compatible Software Products (as defined below) distributed by:
Participant, Enterprise or Strategic Members of the Jakarta EE WG who are also licensees under the Jakarta EE Compatibility Trademark License Agreement; or
Guest Members of the Jakarta EE WG, if:
Happy implementation and innovation!
Best Regards,
Tanja
On 2020-04-28 9:11 a.m., Werner Keil
wrote:
Well that's more or less how Payara or TomEE
started ;-)
If Eclipse Foundation and Jakarta EE WG members really have
time and resources to dissect and show the internals of a
compatible implementation, then why not, otherwise that could
be left to vendors.
Who else would regularly update the list of components and
keep track, if say Spring Boot 3 switches from one framework
by Netflix to something else or a vendor includes a number of
features of MicroProfile 6 or 7 under the hood?
Any list of "using Jakarta EE" or similar should not create
an impression of compatibility unless they really passed the
TCK(s).
Werner
Getting back
to one
of Mihai's original points...
> Looking
at what we have now, it seems to me that all I have to do is
take Glassfish,
rebrand it and bam: I have my own certified Jakarta EE
platform.
Almost all
of
the Jakarta EE Compatible Implementations are open-source.
So, yes,
you could take Glassfish, or Wildfly, or Open Liberty, or
..., rebrand
it and bam, you have your own certified Jakarta EE
Platform. But,
as the notes in this string have indicated, there is much
more to this.
Service and support for your own certified Jakarta EE
Platform takes
many resources (people and dollars). If you are looking to
add any
"missing features" maybe in the area of Security, or
Packaging,
or Microservices, it will take additional resources.
MicroProfile
is a good example of filling this hole of Microservices
development. But,
it didn't come cheap. It took several organizations and
individuals
to spend a great deal of resource to develop the multiple
releases of MicroProfile.
The end result of this effort is that many of the Java EE
and Jakarta
EE certified implementations have also implemented
MicroProfile. So,
innovation is not dead. It is alive and well, both within
and outside
of the Jakarta EE walls.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
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:
04/28/2020
06:44
Subject:
[EXTERNAL]
Re: [jakarta.ee-community] Are there no requirements for
Innovation?
Sent
by: jakarta.ee-community-bounces@xxxxxxxxxxx
Hi Mihai,
I hear you and understand
what you
are saying. For exactly this reason I suggested in the
Jakarta EE spec
committee last year that compatible implements list the
components that
they are using here: https://jakarta.ee/compatibility
The idea was a little to submit
something
like the matrix I made a long time ago, see: https://arjan-tijms.omnifaces.org/2014/05/implementation-components-used-by.htmlI think in general it's good to have
a few independent implementations
of every spec (at least two). Otherwise it kinda misses the
point
of being a spec in the first place.
As far as full
implementations are
concerned, and how innovative (different) they are, it's a
more difficult topic.
In the current crop of compatible Jakarta EE
implementations we see
for instance that GlassFish and Payara use the same core-
and external
components. Nevertheless, Payara is not just a rebranding of
GlassFish,
far from it. It has many individual extra features
(MicroProfile, extra
authentication mechanisms, totally different hazelcast based
clustering,
remote EJB over HTTP, etc etc). JEUS has many similar
components as
well, but is not a GlassFish derivative; it's a unique
server product that
just uses most of the GlassFish components for the separate
APIs.
WildFly and JBoss EAP are
basically the
same though, where EAP is essentially a specific snapshot
from the WildFly
branch and then stabilised/hardened (extra bug fixes, tests,
secure build,
etc) and supported. So as products they are two different
things and it
makes sense IMHO to certify those separately.
With Piranha we're also trying to
build
a Jakarta EE product, and it takes a middle approach kinda
like JEUS but
also like the now defunct Jon AS; all the server bits and
the Servlet,
JNDI and some other implementations are our own code, but
for Jakarta Faces,
Jakarta REST etc we integrate existing implementations.
Kind regards,
Arjan Tijms
On Tue, Apr 28, 2020 at 11:48 AM
Mihai
A. <amihaiemil@xxxxxxxxx>
wrote:
Hi Werner, hi Suren,
By "Innovation" I mean new
implementations of certain specs, not necessarily adding
proprietary functionalities.
Take JAX-RS for example. Even if
there
is an implementation which can be reused in any platform, I
would ask the
platform implementors to
come up with their own JAX-RS
implementation:
maybe they'll come up with a better one. One that is faster,
with less
bugs, better exception messages etc.
Of course, you have to let people
reuse
especially opensource products if they want, but I think
there should
be a requirement for a
minimum of new implementations.
Best regards,
Mihai
On Tue, 28 Apr 2020 at 12:06,
Werner
Keil <werner.keil@xxxxxxxxx>
wrote:
Hi,
Not sure, what you mean with
"rules"
but I assume it's APIs or specs?
CXF implements mainly WS related
JSRs
like JAX-WS, but so far it doesn't look like it migrated to
Jakarta EE
yet.
Weblogic on the other side was at
least
until Java EE 7 compatible with the Full Profile, it has not
shown any
signs of doing this for Jakarta EE 8, but let's see. Tomcat
was the RI
for Servlet a long time ago, Jetty hopes to be compatible
with the new
Jakarta EE Servlet spec and maybe others (I heard from its
leadership team)
and Helidon again I am not aware, that it passes the Servlet
TCKs, but
it should pass a few MicroProfile TCKs.
There are other examples for
projects
that use the Servlet spec, Spring probably the most commonly
known.
I'm not entirely sure, what these
examples have to do with innovation, but there are some new
Jakarta EE
specs especially NoSQL that seem pretty innovative and
recent, although
they could take a bit before they are stable and mature
enough for the
platform.
Werner
On Tue, Apr 28, 2020 at 12:57 AM
Suren
Konathala <konathalasuren@xxxxxxxxx>
wrote:
My POV:
JakartaEE (don’t know much about
CXF)
is standards/specifications https://jakarta.ee/specifications/
To make sure your application
works per-JakartaEE
standards, it needs to follow/implement (say) A,B,C rules.
JakartaEE (and most standards)
define
these A, B, C rules and leave the implementation details to
the implementor.
As an implementor, develop your
software
to conform to A,B,C to be JakartaEE Complaint + do whatever
on top of it
(your innovations). Obviously the better your
innovations/makes things
easy/simple for users the more adaptable your
product/service is.
As an example: All the below are
servlet
containers + (additional features): Apache Tomcat, Jetty,
Weblogic, Helidon
Thanks
Suren
On Sun, Apr 26, 2020 at 5:53 AM
Mihai
A. <amihaiemil@xxxxxxxxx>
wrote:
Hi All,
I know I may be late to the party
with
the following question, but it just struck me the other day:
are there
no innovation requirements for certifying a platform as
Jakarta EE compatible?
Looking at what we have now, it
seems
to me that all I have to do is take Glassfish, rebrand it
and bam: I have
my own certified Jakarta EE platform.
Or take Apache CXF and other bits
and
pieces implementing the required specs, put them together
under a new brand
and again, jackpot!
Shouldn't there be a requirement
for
a minimum of actual implementation effort?
Or maybe there are such
requirements
and I'm not aware of them...
Best regards,
Mihai
--
amihaiemil.com
https://www.github.com/amihaiemil
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
--
amihaiemil.com
https://www.github.com/amihaiemil
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
--
Tanja Obradovic
Jakarta EE Program Manager | Eclipse Foundation, Inc.
Twitter: @TanjaEclipse
Eclipse Foundation: The Platform for Open Innovation and Collaboration