task for native2ascii

[Andrew Sudell <as...@Op.Net>]

Is there any interest in a task do wrap native2ascii?  I've built a
prototype and am more than willing to contribute it if there's 
interest.

My notion is to require the input and output files, since stdin and
stdout don't seem to make much sense in the context of ant (or any
batch build).  I also figure to support encoding and reverse as
optional attributes.  So, for example

<native2ascii encoding="EUCJIS" src="SomeResoure.euc"
    dest="SomeResource_ja_JP.java" />

Would convert SomeResource.euc, in EUC encoded JIS to Ascii with
escaped Unicode creating SomeResource_ja_JP.java.

Creating a task for every file seems a bit tedious, but off hand
I don't see a good alternative, since to the relationship between
input and output are somewhat arbitrary.

I have a project at work that's presently using exec to do this,
and it seems like a reasonable thing to do this weekend it there's
interest.

Drew
-- 
    Drew Sudell        asudell@acm.org         http://www.op.net/~asudell

Re: task for native2ascii

[Hiroaki Nakamura <hn...@mc.neweb.ne.jp>]

"Andrew B. Sudell" wrote:
> 
> Hiroaki Nakamura writes:
>  > Andrew Sudell wrote:
(snip)
>  > 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="_ja_JP.java" 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 _ja_JP.properties.  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
sun.tools.native2ascii.Main.main(String[] 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) hnakamur@mc.neweb.ne.jp

Re: task for native2ascii

["Andrew B. Sudell" <as...@acm.org>]

Hiroaki Nakamura writes:
 > Andrew Sudell wrote:
 > > 
 > > Is there any interest in a task do wrap native2ascii?  I've built a
 > > prototype and am more than willing to contribute it if there's
 > > interest.
 > 
 > I am very interested.

What I've got is done and working, so I can post that.  But I think
I'd like to resolve the bit about how it works first. 

 > 
 > (snip)
 > > Creating a task for every file seems a bit tedious, but off hand
 > > I don't see a good alternative, since to the relationship between
 > > input and output are somewhat arbitrary.
 > 
 > I suppose that in most cases of using native2ascii, you don't want
 > mix sources files and destination files in the same directory,  so

Actually in the case I'm supporting that's exactly what is being
done.  There are a set of native encoded ResourceBundles with
"arbitrary extensions" that sort of map to encoding.  The make system
I'm migrating them from translates to .java files in the same
directories.

I'm not sure that the smartest thing, but it's what happened.

 > I think it is natural that the native2ascii would be a subclass
 > of MatchingTask and that srcDir and destDir are mandatory attributes.
 > And you can specify source files with the "include" nested tags, or
 > with any other ways built in MatchingTask.
 > 
 > 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="_ja_JP.java" 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.

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.

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?

Drew

-- 
        Drew Sudell     asudell@op.net      http://www.op.net/~asudell

Re: task for native2ascii

[Hiroaki Nakamura <hn...@mc.neweb.ne.jp>]

Andrew Sudell wrote:
> 
> Is there any interest in a task do wrap native2ascii?  I've built a
> prototype and am more than willing to contribute it if there's
> interest.

I am very interested.

(snip)
> Creating a task for every file seems a bit tedious, but off hand
> I don't see a good alternative, since to the relationship between
> input and output are somewhat arbitrary.

I suppose that in most cases of using native2ascii, you don't want
mix sources files and destination files in the same directory,  so
I think it is natural that the native2ascii would be a subclass
of MatchingTask and that srcDir and destDir are mandatory attributes.
And you can specify source files with the "include" nested tags, or
with any other ways built in MatchingTask.

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="_ja_JP.java" includes="*.euc" />

Any other thought?

-- 
)Hiroaki Nakamura) hnakamur@mc.neweb.ne.jp