harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fedotov, Alexei A" <alexei.a.fedo...@intel.com>
Subject RE: [classlib] Preprocessor
Date Tue, 31 Oct 2006 09:42:26 GMT

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:geir@pobox.com]
>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:
>>> Do you think we need a lot of them?
>> I don't think we are excluding any option for maintaining similar
>> streams (5.0 & 6.0, SE & ME, etc.) it's just a discussion at the
>> 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,
>> post-processing, aspects, ...) that we choose to solve the problem.
>> I'm sure we wouldn't even want simple branching without a decent
>> 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
>> has broad tooling support.
>> Regards,
>> Tim

View raw message