+1 we already talked a bit about it and thought geronimo/specs was the place but another project could work too.
My goal is mainly to get something consistent. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-16 20:35 GMT+02:00 David Jencks <david_jen...@yahoo.com>: > My recollection of history (no doubt biased and inaccurate)…. > > Geronimo originally needed maven-accessible and plausibly maven-metadata'd > jars, and tomcat was extremely maven-unfriendly at the time (and wasn't set > up to easily consume maven artfiacts). I think we (geronimo) copied the first > one (servlet 2.3??), and I think I recall adding the stuff for at least one > of the later versions myself. > > Later on Geronimo needed osgi bundles… > > If there's any interest in trying to minimize the number of places spec api > code is kept I still sort of like the idea of it all being in one place, > maybe we could investigate something like giving any other-project committer > with interest in working on a spec jar commit rights in geronimo. I don't > think spec jar releases have ever been a big timing/delay problem. > > thanks > david jencks > > On May 16, 2014, at 7:32 AM, Mark Thomas <ma...@apache.org> wrote: > >> On 16/05/2014 07:59, Romain Manni-Bucau wrote: >>> Hello guys, >>> >>> Hope I didnt miss a thread dealing with it, if so please just redirect me. >>> >>> Tomcat made the choice to do its own API jars. That's not a big deal >>> by itself but wonder why not putting them with all "EE" api jars of >>> Apache, ie in geronimo specs subproject: >>> http://svn.apache.org/repos/asf/geronimo/specs/trunk/ >> >> I suspect it stems from the fact the Tomcat was originally the reference >> implementation for a number of those. >> >>> It concerns mainly: >>> * el >>> * websocket >>> * jsp >>> * servlet >>> >>> Just to give you a bit more background, this question doesn't come >>> from nowhere. In TomEE we use geronimo API for almost everything >>> excepted some tomcat provided apis (servlet, jsp) until today. But >>> since recent Tomcat 7 got - thanks to Tomcat 8 - a refactoring of EL >>> part, geronimo-el and tomcat-el were no more compatible. In other >>> words TomEE was broken cause AstValue was refactored and method >>> matching more dedicated to BeanELResolver in tomcat but not in >>> geronimo. >> >> Doesn't that simply mean that the refactoring in Tomcat has exposed a >> bug in the Geronimo EL API? >> >>> Wonder if we should/can try to get something consistent accross ASF. >> >> Assuming that Geronimo is using the Tomcat implementations I wonder why >> the project felt the need to produce their own API JARs. Or are they >> just (old?) copies taken from Tomcat originally? >> >>> wdyt? >> >> From experience with re-using components from Commons, Tomcat would >> almost certainly want to keep a local copy - even if that was an svn >> copy of some common version - else releases can start to experience >> noticeable delays waiting on a release of a dependency. >> >> Mark >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
