Well, TomEE was and still IS MicroProfile-1.0 compatible! MP-1.0 did only require CDI-1.2, JAX-RS-2.0 and JSON-P-1.0 We ship all that, thus we are MP-1.0 compatible.
With later versions of MP the following important specs got added * microprofile-config -> implementation is Apache geronimo-config (requires Java8) * microprofile-rest -> part of CXF-3.2.2 (JAX-RS-2.1, requires EE8, Java8) * microprofile-fault-tolerance -> implementation is geronimo-safeguard (requires Java8) Given that. I think the quickest way is to add those to TomEE8 and then think about how to probably backport those to TomEE7. But before doing that we must finish the discussion about dropping Java7 support. And then again this would better go hand-in-hand with moving from TomEE-7.0.x to TomEE-7.1.x Also note that any user can himself add the mp libs listed above and use the programming model without any restrictions. LieGrue, strub > Am 28.02.2018 um 10:31 schrieb Andy Gumbrecht <agumbre...@tomitribe.com>: > > Hi All, > > Good to see talk on moving TomEE into the MP scene. > > The MP landing page of interest is this one: > https://wiki.eclipse.org/MicroProfile/Implementation > > As we can see, TomEE is a long way behind here. > > I feel that we need to act 'really fast' to get TomEE on that board as soon > as possible, even if it is 'just' a distribution with mp-config enabled - > That would give us two hits on that board with little effort, mp 1.0 and > config 1.2. > > I don't think we should be waiting to get as much in as possible before > releasing something, it should be our priority to release something now. That > could easily be TomEE 7, and 8 soon after. In fact, the longer we wait, the > less significant TomEE will become to MP. > > I don't think it would be too hard to maintain the 7 and 8 versions by adding > mp-impls as soon as we have them available. > > As you know, all I wanted to do recently was to open up mp modules space for > this work to begin on getting TomEE up to spec - Again, not to create > implementations or libraries. I still believe this is a logical approach, to > have a module per spec in TomEE. These modules should be focusing on getting > the current impls of choice (Wherever they come from!) integrated into TomEE, > and passing the corresponding TCKs provided by MP. I'd personally like to see > TomEE MP modules high up in the project hierarchy and not buried, but I will > leave that up to you guys for obvious reasons. I'd just ask that any one of > you guys to get the ball rolling on this so that we can maybe divide the work? > > Andy. > > > On 27/02/18 16:02, Roberto Cortez wrote: >> Thanks Romain, >> I'll have a look into JL work. >> Cheers,Roberto On Tuesday, February 27, 2018, 2:53:50 PM GMT, Romain >> Manni-Bucau <rmannibu...@gmail.com> wrote: >> Hi Roberto, >> >> JL already has some work which is close to be imported in Geronimo >> dedicated project so maybe ensure you don't duplicate the effort here. >> Also we'll need to have a tomee MP module (which can compiles or assemble >> modules) on Java 8 otherwise we can't support any MP spec since they all >> require java 8 quite hardly in their API so probably time to add to >> apache-tomee module a mp assembly which would import java 8 modules (vs wp >> and fp will not). >> >> >> >> >> Romain Manni-Bucau >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> <https://rmannibucau.metawerx.net/> | Old Blog >> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> >> | >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >> >> 2018-02-27 15:38 GMT+01:00 Roberto Cortez <radcor...@yahoo.com.invalid>: >> >>> Hi, >>> Thank you for the discussion. >>> I do believe that we should provide a MP 1.3 implementation under TomEE 7. >>> As we know, moving from major versions is sometimes slow in a lot of >>> organizations, even if the upgrade only requires a zip file. >>> So, I'll look into integrating some of the work under TomEE 7 and then 8. >>> Cheers,Roberto On Thursday, February 22, 2018, 9:02:44 AM GMT, Romain >>> Manni-Bucau <rmannibu...@gmail.com> wrote: >>> >>> 2018-02-22 9:45 GMT+01:00 Gurkan Erdogdu <gurkanerdo...@yahoo.com. >>> invalid>: >>> >>>> Even if we use IRC or similar tools, we need to get all of these >>>> discussion to our mailing lists. ASF main idea is to use the mailing >>> lists >>>> for these discussions. I think such decisions taken from other places >>>> really kills the projects and community >>>> >>> You read it wrong, the decisions have been done on the list the asf way. >>> The community and user activity doesn't always go through the list since it >>> requires steps to enter whereas twitter and irc are no step - guess it is >>> why we miss activities on the list. >>> >>> >>>> CheersGurkan >>>> >>>> On Thursday, February 22, 2018, 11:38:02 AM GMT+3, Romain Manni-Bucau >>> < >>>> rmannibu...@gmail.com> wrote: >>>> >>>> 2018-02-22 9:35 GMT+01:00 Gurkan Erdogdu <gurkanerdo...@yahoo.com. >>>> invalid>: >>>> >>>>>>>> After all the same (active!) people are involved in most of those >>>>> projects anyway. When you have lots of similar projects, it is not easy >>>> to >>>>> create and maintain the healthy community , only couple of active >>>>> developers works on these projects without general community consensus >>> . >>>> I >>>>> prefer to have one project which covers all of these similar >>>> technologies. >>>> Except it doesn't work in practise I think - we tried and failed - cause >>>> communities are actually different. Sadly it goes through IRC/twitter a >>> lot >>>> and seems mails are no more mainstream but core dev are the same, users >>> are >>>> not. >>>> If we see a cost we can't pay we'll probably merge them but it is clearly >>>> not the case today so no real point merging them and loosing users. >>>> >>>> >>>>> CheersGurkan >>>>> On Thursday, February 22, 2018, 11:10:57 AM GMT+3, Mark Struberg >>>>> <strub...@yahoo.de.INVALID> wrote: >>>>> >>>>> > 4. Hammock: real MP server based on cdi (tomee cant be that) >>>>> Well, MP defines just a _minimal_ requirement and a set of additional >>>>> technologies.TomEE can easily implement these and call itself a >>>>> MicroProfile server. >>>>> BUT: it will be really hard to trim down TomEE to this bare minimum >>> what >>>>> the MP specification defines. It will always be bigger than Meecrowave >>> or >>>>> Hammock! But does 'bigger' mean fat? No, 40MB is certainly more weight >>>> than >>>>> 9MB, but in most cases it doesn't even matter.In some it does though. >>>>> >>>>> >>>>> For me there is a clear and concise way of scaling: >>>>> * if you only need servlets and no DI -> use pure Tomcat * if you also >>>>> need CDI and JAX-RS -> use Meecrowave (or Hammock)* if you need XA, >>>> JAX-WS, >>>>> EJB, etc -> use TomEE >>>>> After all the same (active!) people are involved in most of those >>>> projects >>>>> anyway. >>>>> LieGrue,strub >>>>> On Thursday, 22 February 2018, 07:54:27 CET, Romain Manni-Bucau < >>>>> rmannibu...@gmail.com> wrote: >>>>> >>>>> Hi Gurkan, >>>>> >>>>> All has clarified after your mail: >>>>> >>>>> 1. Geronimo: ee* umbrella project for subspec >>>>> 2. Meecrowave: light cxf/tomcat/johnzon/owb server (no MP target by >>>>> itself!), name is not even on the website. >>>>> 3. TomEE: javaee server + tomee or RA specific projects >>>>> 4. Hammock: real MP server based on cdi (tomee cant be that) >>>>> >>>>> So there is no real confusion since the overlaps are very small once >>> you >>>>> checked out the projects IMHO. >>>>> >>>>> Le 22 févr. 2018 07:43, "Gurkan Erdogdu" <gurkanerdo...@yahoo.com. >>>> invalid> >>>>> a écrit : >>>>> >>>>> Hi allSeveral months ago I advised to create another profile under >>> TomEE >>>>> (or create another TLP project) instead of duplicating the work in >>>>> Meecrowave project but Romain and Mark rejected. Now, come to the same >>>>> point :) There are lots of separate projects (or subprojects, or >>> modules) >>>>> in Apache (Geronimo, TomEE, Meecrowave. I think all of these modules >>> must >>>>> belong to TomEE. Lots of users are confused with this >>>>> >>>>> https://lists.apache.org/thread.html/9d6058ba109f27cd74c29cd93bebfc >>>>> e29160145723407e203e43d145@%3Cdev.openwebbeans.apache.org%3E >>>>> >>>>> CheersGurkan >>>>> >>>>> >>>>> >>>>> On Thursday, February 22, 2018, 12:41:19 AM GMT+3, Romain >>> Manni-Bucau >>>> < >>>>> rmannibu...@gmail.com> wrote: >>>>> >>>>> Le 21 févr. 2018 22:33, "Bruno Baptista" <bruno...@gmail.com> a >>> écrit : >>>>> Hi All, >>>>> Is it a given that in the future we will use on TomEE both: >>>>> >>>>> https://github.com/apache/geronimo-config >>>>> https://github.com/apache/geronimo-safeguard >>>>> >>>>> Can we assume that from now on? >>>>> >>>>> >>>>> In the MP distro probably yes. Stack (dependencies) will pby be refined >>>> for >>>>> safeguard since current one is not that friendly for tomee IMHO - >>> tomcat >>>>> classloading part + size - but not yet a blocker. Config is good for a >>>>> tomee-mp. >>>>> >>>>> Cheers >>>>> >>>>> Bruno Baptista >>>>> http://twitter.com/brunobat_ >>>>> >>>>> >>>>> >>>>> On 21-02-2018 18:49, Roberto Cortez wrote: >>>>> >>>>>> Hi guys, >>>>>> I've been looking a little bit in how to use some of the existent >>>> Apache >>>>>> MP implementations with TomEE and here are some ideas / conclusions. >>>>>> MicroProfile Configuration:Using https://github.com/apache/ >>>>> geronimo-config >>>>> . >>>>>> Just adding the jar, plus API to TomEE libs seems to be enough. >>>>>> MicroProfile Fault Tolerance:Using https://github >>>>>> .com/apache/geronimo-safeguard. Added the jars and the API to TomEE >>>> libs >>>>>> and also required to set TomEE configuration >>> tomee.webapp.classloader. >>>>> enrichment.prefixes >>>>>> to safeguard-impl. This is to add the required CDI Beans that are >>> part >>>> of >>>>>> safeguards into the webapp context. With this, it seems to work just >>>>> fine. >>>>>> If this would be part of the dist, I guess we would need to add the >>>>>> required CDI Beans into org.apache.openejb.cdi.CdiScanner. >>>>>> MicroProfile Rest Client:Apache CXF added a MP Rest Client module. >>> The >>>>>> issue is that it is added into the 3.2.x line, which is JAX-RS 2.1. >>> If >>>> we >>>>>> look into the MP spec, the Rest Client should be compatible with >>> JAX-RS >>>>>> 2.0, which is implemented in CFX 3.1.x line. Upgrading TomEE to CFX >>>> 3.2.x >>>>>> doesn't really work due to the JAX-RS 2.1 dependency. As a >>> workaround, >>>>> I've >>>>>> also tried to use just the CFX 3.2.x module lib MP Rest Client, but >>>> there >>>>>> is some dependent code. Made a few local changed and got it to work, >>>> but >>>>>> ideally, the MP Rest client should be ported back to CFX 3.1.x to >>>> support >>>>>> MP 1.3. >>>>>> Couldn't find any other Apache implementations for the other MP >>> specs. >>>>>> I've also think that it could be interesting to distribute a TomEE >>>>> flavour >>>>>> with just the MP stuff, to slim down the binary. >>>>>> Any thoughts? >>>>>> Cheers,Roberto >>>>>> >>> > > -- > Andy Gumbrecht > https://twitter.com/AndyGeeDe > http://www.tomitribe.com > https://www.tomitribe.io > > > Ubique >
