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