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 > > > >> > > > >> > > > > > > > > >
