You missed one point: Geronimo is NOT geronimo server only or you likely missed a big part of asf ecosystem since geronimo touches most of EE projects and some OSGi ones and it is intended to continue and it is maintained by asf community.
You also assume things regarding TomEE which are unfounded. So long story short: if you don't know don't say anything please, it will avoid issues for all of us. Thanks and sorry to have polluted tamaya thread to clean up these errors, Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-07-20 16:55 GMT+02:00 Werner Keil <[email protected]>: > Have to ask Mark why he suggested Geronimo/EE in the first place instead of > Tamaya. > > If a hypothetical future version of Geronimo came up some day in the future > let's see, but a project that has not released anything for over 3 years is > highly inactive at most. And most people wold just say it's dead in today's > fast-paced IT community. > > Your company (I assume you still work at Tomitribe) is the main contributor > of TomEE and offers commercial support named after TomEE. There is no > evidence of commercial support around Geronimo by Tomitribe. If so you must > be hiding it very well;-) > > It's out of question how big the stake of JBoss/Wildfly is. Just working > for another big Global Player where it plays the central role of its > Enterprise server ecosystem (despite most solutions being Spring based with > various web frameworks from Struts to Wicket) Oracle feels pressure from > more than just Spring, Lightbend or Red Hat, and while it has not actively > worked on Glassfish for some time now (v5 should be the RI of Java EE 8 > unless something changes) but e.g. Paraya offers commercial support: > http://www.payara.fish/customers > > Where is this kind of support for Geronimo? I'm not saying it's not running > somewhere. Probably even in production, but that's usually a system nobody > wants to touch for many years. And unless a new version is released pretty > soon I bet it won't be Geronimo they'll replace it with. > > Werner > > On Wed, Jul 20, 2016 at 4:34 PM, Romain Manni-Bucau <[email protected] > > > wrote: > > > Didn't want to feel the trolls but you say too wrong statements we > > shouldn't let be public without corrections in this last one > > > > 2016-07-20 16:29 GMT+02:00 Werner Keil <[email protected]>: > > > > > Why that's not true. JPA historically has more ties to TopLink > including > > > the RI now at EclipseLink I also said that earlier. > > > You said Hibernate became a de-facto blueprint. Which is not the case, > it > > > may have become a bit more popular for various reasons (Spring > supporting > > > it, then major competitor Red Hat buying its team and taking over > > > development) but it was never a 1:1 blue print or starting point for an > > > Oracle-led JSR. > > > > > > Structurally maybe JSR 330 is closest to what was and still is at > Google > > > Guice. See https://github.com/google/guice/wiki/JSR330, though JavaDoc > > > suggests they're also not 1:1 copies. > > > > > > After seemingly panic that Tamaya could become a RI for a future spec > > (and > > > as of now it looks like the best option, take Pluto and others in the > > past) > > > you suddenly pulled out the "dead" Geronimo card. > > > > > > > Geronimo is NOT dead, this clearly means you don't know what G is. The > > server gets only very low activity but other projects are quite active > for > > the whole ASF ecosystem. > > > > > > > A few patches here and there seem to exist > > > http://svn.apache.org/viewvc/geronimo/ but not a single release since > > > 2013, > > > sorry, but that's as dead as it can be. Tomitribe works a lot on TomEE > > > right now in the EE space the de facto only real place of activity at > > > Apache other than e.g. Pluto (following Portlet 3, but it'll run on any > > > Tomcat or TomEE container, no need for Geronimo there) > > > > > > > > That's an assumption as well > > > > > > > Geronimo makes no effort for Java EE 7 compatibility for "religious" or > > > other ideological reasons I know from the EC discussions or those in > the > > EE > > > umbrella EGs. The lack of activity also would not qualify it for EE 7 > > > compliance, so it's dead you can't ignore that. > > > > > > > > Why do you speak of EE there, what's the link you do with Tamaya? > > > > > > > With initial contributions sometimes based on an entire projects or > parts > > > of it JSR 354 is also not JodaMoney, though Stephen probably would have > > > hoped for that. Nevertheless it's incompatible parallel final > structures > > > and missing API (BigMoney vs. Money no common denominator like > > TemporalUnit > > > or TemporalAmount were created behind 310) and total lack of conversion > > or > > > an SPI just disqualify it for a standard. And you see the extension > > points > > > are what's used of JSR 354 ever since it went Public Draft. > > > > Cheers, > > > Werner > > > > > > > > > On Wed, Jul 20, 2016 at 4:06 PM, Mark Struberg > <[email protected] > > > > > > wrote: > > > > > > > This now seems to directly contradict to what you said multiple times > > > > before in this thread. > > > > > > > > Quoting mails from you : > > > > "A JSR is rarely just a single framework or project only changing its > > > > package name. JSR 363 was probably one of the few exceptions“ > > > > "Hibernate vs. JPA is also an interesting read …“ > > > > You literally mentioned dozen examples where open source projects did > > > > _not_ become a JSR 1:1 and don’t care about backwards compatibility > > with > > > > existing solutions. > > > > > > > > > > > > > > The other points are valid but everyone still just keeps talking > > around > > > > > "Yes we need an SPI" nobody so far talked about what it may contain > > or > > > > what > > > > > could be added/removed. > > > > > > > > Even my initial mail DID contain exactly that. As did dozen > subsequent > > > > posts… > > > > > > > > LieGrue, > > > > strub > > > > > > > > > > > > > > > > > > > > > Am 20.07.2016 um 15:48 schrieb Werner Keil <[email protected] > >: > > > > > > > > > > You asked about a possible JSR "not bothering about existing stuff" > > and > > > > > based on what a vast majority of EC members agree on I told you > > that's > > > > not > > > > > the case. Question answered. > > > > > > > > > > Plus popular examples where existing open source projects ended up > as > > > 90% > > > > > blueprint for a JSR/JDK part like > > > > > https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html > > > > > based on > > > > > http://www.joda.org/joda-time/apidocs/org/joda/time/Duration.html > > > > > > > > > > Ok there's also another Duration class added with JavaFX, but let's > > not > > > > go > > > > > there;-) > > > > > > > > > > > > > > > The other points are valid but everyone still just keeps talking > > around > > > > > "Yes we need an SPI" nobody so far talked about what it may contain > > or > > > > what > > > > > could be added/removed. > > > > > > > > > > Werner > > > > > > > > > > > > > > > On Wed, Jul 20, 2016 at 3:39 PM, Mark Struberg > > > <[email protected] > > > > > > > > > > wrote: > > > > > > > > > >> Why do none of your mails seem to direcly reply to the question > > asked > > > in > > > > >> the mail before? > > > > >> Most of them seem totally out of context to me. > > > > >> Or is it just me who feels offended by that? > > > > >> > > > > >> LieGrue, > > > > >> strub > > > > >> > > > > >> > > > > >>> Am 20.07.2016 um 15:06 schrieb Werner Keil < > [email protected] > > >: > > > > >>> > > > > >>> Not exactly, because it's a broad consensus among JCP EC members > (I > > > am > > > > >> just > > > > >>> one Individual) that an idea should get the "reality check" in > most > > > > cases > > > > >>> via an established Open Source project. > > > > >>> > > > > >>> > > > > >>> So while the codebase of a new JSR (see 375) would normally be a > > > green > > > > >>> field contribution from scratch, if EG members did a lot in an > > > existing > > > > >>> open source project, then there are often significant > similarities > > > with > > > > >>> those projects. > > > > >>> > > > > >>> JSR 354 was started by Victor by more or less accepting JodaTime > > as a > > > > >>> template. A few types remained almost unchanged (and everyone > > > > especially > > > > >>> Stephen is mentioned as authors) while others were refactored, > > > removed > > > > or > > > > >>> new ones added. java.time although it is highly inspired by > > JodaTime > > > on > > > > >> the > > > > >>> "developer facing front" with types like Duration, LocalDate, > etc. > > > did > > > > >> get > > > > >>> an "API/SPI in a closet" mostly thanks to Roger Riggs by Oracle. > > The > > > > >> names > > > > >>> changed significantly, the term "Temporal*" was only introduced > at > > a > > > > >>> relatively late stage. IMHO the biggest design mistake in the API > > is > > > to > > > > >>> directly reference the concrete implementation Duration in > > > > >>> > > > > >> > > > > > > > > > > https://docs.oracle.com/javase/8/docs/api/java/time/temporal/TemporalUnit.html > > > > >> . > > > > >>> There is no logical reason why not to use the "API" element > > > > >> TemporalAmount > > > > >>> here and call the damn thing "getAmount()" or similar. Baking the > > RI > > > > into > > > > >>> an API is a no-go. You won't see this in any other JSR I reviewed > > or > > > > >> voted > > > > >>> on. Of course it was tightly embedded into OpenJDK and Stephen > > > himself > > > > >>> claims there will never be a need for an independent > > implementation, > > > > but > > > > >>> then why not stop the JSR and just turn it into a JEP that also > > > > existed. > > > > >> It > > > > >>> was silly and unfortunate in this case, but just because > something > > is > > > > in > > > > >>> the JDK doen't mean it has to be a bad or useless API, take > > > Collections > > > > >> for > > > > >>> example. There's an independent implementation of it now at > Eclipse > > > by > > > > >>> Goldman Sachs. > > > > >>> > > > > >>> JSR 354 may not have a full implementation yet, but large players > > > like > > > > >>> Zalando created exchange rate providers and extended it with > > Jackson > > > > >>> Binding or Bean Validation support, so I guess the extension > > > mechanisms > > > > >>> created there worked;-) > > > > >>> > > > > >>> JSR 275 was an interesting case because Open Geospatial > Consortium > > > did > > > > >> not > > > > >>> bother that it was stopped. It's part of another standard GeoAPI > by > > > OGC > > > > >>> till a new version replaces it with 363. It is almost Final, but > I > > > > guess > > > > >>> the OGC wants to be on the safe side and wait till 1.0 is really > > out > > > > this > > > > >>> time?;-) > > > > >>> > > > > >>> Werner > > > > >>> > > > > >>> > > > > >>> On Wed, Jul 20, 2016 at 2:47 PM, Mark Struberg > > > > <[email protected] > > > > >>> > > > > >>> wrote: > > > > >>> > > > > >>>>> > > > > >>>>> Am 20.07.2016 um 13:10 schrieb Werner Keil < > > [email protected] > > > >: > > > > >>>>> > > > > >>>>> > > > > >>>>> That's where I suggested, that the minimum an SPI must provide > is > > > the > > > > >>>>> equivalent to PropertySource and maybe PropertySourceProvider. > > > > Allowing > > > > >>>>> those extensions to still work with a future design. > > > > >>>> > > > > >>>> Yes, there is finally something we agree on ;) > > > > >>>> > > > > >>>> I probably do care less about existing extensions than you. Any > > new > > > > JSR > > > > >>>> imo doens’t need to bother about existing stuff. I think we > agree > > on > > > > >> this > > > > >>>> part as well, right? > > > > >>>> > > > > >>>> The main reason why I think we need an SPI is because the > > > application > > > > >>>> otherwise has no way to plug in the stuff they need. > > > > >>>> > > > > >>>> That would be like bean-validation without custom > > > > >>>> Constraint+ConstraintValidator. Such a spec would not be worth > the > > > > >> energy > > > > >>>> imo. > > > > >>>> > > > > >>>> LieGrue, > > > > >>>> strub > > > > >> > > > > >> > > > > > > > > > > > > > >
