Guys, remember, you should put your energies into Tamaya. For the other stuff, I suggest you do a hangout together or meet for a big cup of coffee! Much more efficient and much more fun, believe me ;)
2016-07-20 17:00 GMT+02:00 Mark Struberg <[email protected]>: > He don’t need to ask because he KNOWS. > It’s obvious for all who know about G. > The Geronimo server is pretty much stale, but ALL the rest of this project > is well alive! > > Geronimo is nowadays kind of a ‚EE commons‘ project. > > And I also have no clue what Tomitribe has to do with that? > TomEE btw takes a _huge_ bunch of stuff from the Geronimo projects, and > TomEE committers _actively_ contribute to Geronimo! > E.g. xbean, the geronimo transaction manager and JTA, etc, etc > > Please inform yourself before you spread wrong accusations on public lists! > > LieGrue, > strub > > > > Am 20.07.2016 um 16:55 schrieb 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 > >>>>>> > >>>>>> > >>>> > >>>> > >>> > >> > > -- *Anatole Tresch* PPMC Member Apache Tamaya JCP Star Spec Lead *Switzerland, Europe Zurich, GMT+1* *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> * *Twitter: @atsticks, @tamayaconf*
