geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rex Wang <rwo...@gmail.com>
Subject Re: [VOTE] Release Geronimo Customized Tomcat 7.0.0.0 (Second Try)
Date Thu, 06 May 2010 01:24:36 GMT
Agree, We can just add a comment in its pom, which records the revision our
external tomcat based on.

-Rex

2010/5/6 Ivan <xhhsld@gmail.com>

> I think that our four version numbers could help us, while Tomcat always
> has three version number. In next iteration, we call our version 7.0.0.1,
> which means more changes are merged from Tomcat 7 dev tree ......
>
> 2010/5/5 Vamsavardhana Reddy <c1vamsi1c@gmail.com>
>
>
>>
>> On Wed, May 5, 2010 at 7:45 PM, Kevan Miller <kevan.miller@gmail.com>wrote:
>>
>>>
>>> On May 4, 2010, at 1:56 PM, Joe Bohn wrote:
>>>
>>> >
>>> > +1 (assuming the potential license issue mentioned below is not an
>>> issue)
>>> >
>>> > I was able to build and run the new tomcat image.
>>> >
>>> > The license issue pointed out last time is now resolved but there is
>>> one other potential issue.  I noticed a number of files under jasper-el that
>>> are generated using JJTree & JavaCC and so have the following header but
no
>>> Apache license header.  For example:
>>> >
>>> > /* Generated By:JJTree&JavaCC: Do not edit this line. ELParser.java
*/
>>> >
>>> > Some other generated files include both a generated header and which is
>>> immediately followed by the Apache license header.  This seems a little
>>> better to me.  However, I see that we have released these without the Apache
>>> header in earlier versions (and Tomcat as well) - so I presume there must be
>>> some valid justification for not including an Apache License header in these
>>> files.  Just pointing it out now in case it really needs some attention and
>>> has just escaped being noticed until now.  Comments?
>>>
>>> I've certainly noticed them in the past... Machine generated files do not
>>> require license headers. So, IMO, these files are fine.
>>>
>>> I do have a question about the version #. IIUC, we are releasing 7.0.0
>>> prior to the TC community. There may be fixes applied to the Tomcat dev tree
>>> prior to their 7.0 release. So, this release may not exactly match the
>>> functionality of the tomcat release. Is everyone evaluating that in their
>>> decision?
>>>
>>> --kevan
>>
>>
>> I think there are two many zeros in the version number too. How about we
>> use a version number similar to "6.0.18-G678601" like we have in G 2.x
>> builds?
>>
>> --
>> Vamsi
>>
>
>
>
> --
> Ivan
>



-- 
Lei Wang (Rex)
rwonly AT apache.org

Mime
View raw message