Geir, I tried this preprocessor staff for Java in my previous life. From my experience the maintenance effort is higher for this solution than for Source Control.
1. I faced first time how slow regular expressions on Java could be. 2. Perl worked fine but no one around me could understand my pre-processing scripts and maintain them. 3. The girl from Ireland beat my clever scripts with Sun's TeamWare and text editor. +1 for Source Control With best regards, Alexei Fedotov, Intel Java & XML Engineering >-----Original Message----- >From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] >Sent: Tuesday, October 31, 2006 12:28 PM >To: harmony-dev@incubator.apache.org >Subject: Re: [classlib] Preprocessor > > > >Tim Ellison wrote: >> Mikhail Fursov wrote: >>> What are the reasons to exclude the most standard solution here: >branching. >>> Do you think we need a lot of them? >> >> I don't think we are excluding any option for maintaining similar code >> streams (5.0 & 6.0, SE & ME, etc.) it's just a discussion at the moment. >> >> Similarly, I'm not advocating the use of aspects for maintaining >> different code streams; but rather I was saying that IDE support is >> likely going to be a requirement for any technology (apt, preprocessor, >> post-processing, aspects, ...) that we choose to solve the problem. >> >> I'm sure we wouldn't even want simple branching without a decent merge >> tool to keep things in sync. > >Yes - that's what I'm scared of. A branch solution sounds like it >leads to much misery and woe, because i think all the factors that make >this such an interesting problem for which a pre-processor is a valid >solution this implies the requirement of some kind of conditional merge > >> >> I agree with Geir that we should endeavour to choose a technology that >> has broad tooling support. >> >> Regards, >> Tim >>
