Geronimo clearly has a PR and visibility problem if there is activity. If the website says "Version 3.0 in development" and so does JIRA. There are no tickets and http://www.mail-archive.com/dev%40geronimo.apache.org/ has a single page going back to over a year ago (1/3 of that page is simply filled by Mark's pseudo-JSR)
Those are not signs of a vibrant project sorry guys. I know, the Portals and Pluto page also does not reflect Portlet 3 on the outside yet, but there are messages in the mailing list (at least as many for 2016) and a weekly conf call which (because it's at 4pm CET, so too early in most cases) I cannot attend more than maybe once a month or so, but I also participate as good as I can. On Wed, Jul 20, 2016 at 5:23 PM, Werner Keil <[email protected]> wrote: > 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* >> > >
