On Wed, Nov 7, 2012 at 4:32 PM, Dasa Paddock <dpadd...@esri.com> wrote:
> I would try setting encoding="UTF8". I've found that this does fix
> problems like this on Windows.
>
>
Bingo!
Changing the tasks like this:
<fixcrlf srcdir="${BUILD_DIR}/temp" eol="crlf"
excludes="**/*.ttf,**/*.png" *encoding="UTF8"*/>
and
<fixcrlf srcdir="${BUILD_DIR}/temp" eol="unix" excludes="**/*.ttf,**/*.png"
*encoding="UTF8"*/>
fixed the issue.
Apparently the encoding for the FixCRLF task defaults to the default JVM
encoding. I learn something new everyday here :-)
Thanks,
Om
> --Dasa
>
> On Nov 7, 2012, at 4:20 PM, Carol Frampton <cfram...@adobe.com> wrote:
>
> >
> >
> > On 11/7/12 4 :03PM, "Om" <bigosma...@gmail.com> wrote:
> >
> >> Removing these lines from the source-package task :
> >>
> >> <fixcrlf srcdir="${BUILD_DIR}/temp" eol="crlf"
> >> excludes="**/*.ttf,**/*.png"/>
> >>
> >> <fixcrlf srcdir="${BUILD_DIR}/temp" eol="unix"
> >> excludes="**/*.ttf,**/*.png"/>
> >
> > I've been playing with this task as well.
> >
> > You need this task to make the line endings match the type of the kit.
> > Even if the files had native line endings, you would need this unless you
> > want to make the Windows distro on a Windows system and the Mac distro on
> > a Mac.
> >
> >
> > To make the EOF match you can add fixlast="false" since the default is
> > "true". This doesn't help with the encoding issue just the EOL at EOF
> > issue.
> >
> > The task does has an encoding property you can play with. I don't have
> > the garbled problem when I produce the the kits on mac so there is
> nothing
> > for me to test.
> >
> > Carol
> >
> >
> >>
> >> seems to have fixed this issue for both the zip and tar.gz source kits.
> >>
> >> This would also fix the other issue raised on general@i.a.o about the
> >> mismatch between eof eol in the src kit vs. release tag.
> >>
> >> The question is - what are the other repercussions of this change?
> >>
> >> Thanks,
> >> Om
> >
> >
>
>
