Agree, We can just add a comment in its pom, which records the revision our external tomcat based on.
-Rex 2010/5/6 Ivan <[email protected]> > 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 <[email protected]> > > >> >> On Wed, May 5, 2010 at 7:45 PM, Kevan Miller <[email protected]>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
