On Mon, Nov 12, 2012 at 7:58 AM, Carol Frampton <cfram...@adobe.com> wrote:
>
>
> On 11/9/12 7 :37PM, "Om" <bigosma...@gmail.com> wrote:
>
> >Carol,
> >
> >I am not sure if this fixes "all" the problems. But when I diff the files
> >from svn trunk vs. the packaged source kit, I still see some a few .as and
> >.mxml files which seem different because of some reason.
>
> Then we should figure that out but this isn't holding up the installer
> release as far as I know is it? I still have lots of unread emails so I
> may find out in a bit.
>
>
No, its not a blocker for this release. We are still waiting for a third
IPMC vote.
Thanks,
Om
> Carol
>
> >
> >Thanks,
> >Om
> >
> >On Wed, Nov 7, 2012 at 5:11 PM, Carol Frampton <cfram...@adobe.com>
> wrote:
> >
> >> I believe these will fix all the problems:
> >>
> >> <fixcrlf srcdir="${BUILD_DIR}/temp" eol="crlf" encoding="UTF8"
> >> excludes="**/assets/**,**/*.ttf,**/*.png" fixlast="false"/>
> >>
> >> <fixcrlf srcdir="${BUILD_DIR}/temp" eol="unix" encoding="UTF8"
> >> excludes="**/assets/**,**/*.ttf,**/*.png" fixlast="false"/>
> >>
> >> Note the addition of **/assets/** to excludes to cover the .ico files,
> >>the
> >> addition of encoding and the addition of fixlast.
> >>
> >> Carol
> >>
> >>
> >>
> >> On 11/7/12 4 :44PM, "Om" <bigosma...@gmail.com> wrote:
> >>
> >> >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
> >> >> >
> >> >> >
> >> >>
> >> >>
> >>
> >>
>
>
