ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiroaki Nakamura <>
Subject Re: task for native2ascii
Date Sun, 17 Sep 2000 17:33:03 GMT
"Andrew B. Sudell" wrote:
> Hiroaki Nakamura writes:
>  > Andrew Sudell wrote:
>  > About filenames, two cases come to my mind.
>  > case 1: Each pair of a source filename and a destination filename
>  >         have the same name.
>  > case 2: A destination file will be named after a source file
>  >         using some naming rules.
>  > In case 2, a rule might be replacing some string in a source
>  > filename to another string, so the native2ascii can have
>  > two optional attributes, "token" and "value" (named after the Replace
>  > task).  For example, if you change the destination directory to
>  > "foo", Andrew's example will become:
>  >
>  > <native2ascii encoding="EUCJIS" srcDir="." destDir="foo"
>  >     token=".euc" value="" includes="*.euc" />
>  >
>  > Any other thought?
> I sort or like case 1.  Keep the names the same and move directories.
> It lets one avoid a lot of tedious small tasks.  Case 2 imposes the
> notion that the input and output files have some naming convention,
> which isn't really required by the original tool.

Case 1 can be achieved by omitting two optional attributes "token" and "value":
<native2ascii encoding="EUCJIS" srcDir="." destDir="foo" includes="*.euc" />

But I like source files and destination files have different names.
The destination file must obey the Java resource naming rule, like
ending  And I don't like the source files have
the same name as those.  Different name for different contents.
Also, I like having the encoding name as a substring of source
file names, like your example, SomeResoure.euc, that leads to
different names anyway.

> I don't think, however, that I should be altering the semantics of
> native2ascii as I incorporate it into ant.  I suppose those who object
> to lots of small tasks could resort to a script tag and do the
> iteration around the task.  Like as not in most projects the likely
> uses will be message catalogs and there ought not be thousands of them
> per language in a given program.  More likely one per language.

Well, that depends how you organize the resource files.  For example,
IIRC, Visual Cafe 3 was making a property file for each window and dialog,
so you will have many files.  I suppose there are many cases that
you have many resource files.  Thousands of them not likely, but dozens
of them or hundreds of them might be usual.  In those circumstances,
you must edit the build.xml file every time you add a window.  And when
you have that many files, you will like to have some naming convention.

> I think I'm leaning towards the opinion that ant should respect the
> syntax of the tools it provides access to, no matter how inconvenient
> they might be.  Does this seem unfair?

I think that the Ant is great because:
1) It avoids unnecessary tasks by comparing last modified times of
   source files and destination files.  This mechanism do not handle
   depencencies perfectly, but will do in most cases.  It saves a lot
   of time!  And when that something goes wrong, you can clean the
   destination files and re-run all tasks.
2) It can handle set of files scattered in many subdirectories without
   specifying each name of files.  So, once you wrote the build.xml,
   you rarely edit it when you just add source files, thanks to the
   powerful MachingTask.

Oh, I almost forgot.  The native2task should have the first feature.
Compare each pair of a source file and a destination file and not run
the native2ascii when the destination is newer.

And it is nice if you are running native2ascii without Runtime.exec(),
because it save the time and memory of another Java VM running.
I just have a quick look, it might be done by calling[] args).

By the way, "token" and "value" attribute names might have
different names,  because these are the same as the Replace task,
so a user might tend to think the native2ascii task will replace the
word in source file contents, not in source file names.

)Hiroaki Nakamura)

View raw message