Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [classlib] Preprocessor
Date: Tue, 31 Oct 2006 12:42:26 +0300
Message-ID: <8E389A5F2FEABA4CB1DEC35A25CB39CE695089@mssmsx411>
Thread-Topic: [classlib] Preprocessor
thread-index: Acb8zuXHEmU7mSZZTWC8VXWWF6OhDQAABblA
From: "Fedotov, Alexei A" <alexei.a.fedotov@intel.com>
To: <harmony-dev@incubator.apache.org>

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