Anatole, Much appreciated the bullet points and "stories". Instead of just nagging like Waldorf and Statler from the Muppets about everything you don't like about Tamaya ;-D
Will you also create JIRA items or does someone else plan to do so? Thanks, Werner On Wed, Jul 20, 2016 at 5:03 PM, Anatole Tresch <[email protected]> wrote: > 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* >
