<snip>
> > I am working on a patch to the maven dist plugin that makes the crlf
> > filter property configurable. Arnaud pointed out in another thread
> > that there should probably a similar filter applied to make sure "lf"
> > line endings are used in the tar.gz distros. My inclination is to
> > apply this to *all* files in the tar.gz distros by default. It occurs
>
> Won't this cause corruption of .jar, .class, .jpg, etc files?
Doh! Good point. Would need to exclude at least these.
>
> > to me now that because of the "eol=native" svn props, RMs who cut
> > releases on Windows are likely making tars with crlf line endings
> > (since svn will convert files to crlf on checkout). Note that this
> > applies to ant as well as maven-built distros.
>
> And RMs who use Unix will be creating zips with LF line endings...
>
Yes, IIUC, that is the consequence of using "eol=native." Having the
file contents of distros different depending on the OS used to cut the
release does not seem like a good thing to me. Could be I have
something wrong here. Maybe someone who has both unix and Windows
boxes set up can test and see if the the Windows-built distros (from
Windows checkouts) end up with CRLF everywhere (at least for files
with "eol=native").
> [Are there any who use Macs?]
>
> > I will make the unix filter configurable as well, but want feedback on
> > what the default should be, as well as what our policy should be in
> > commons on line endings in tar.gz as well as zip distros.
>
> Ideally the default would depend on the svn:eol-type.
> i.e. if svn:eol-type=native, then convert the file for the appropriate
> native format, otherwise leave alone.
> Dunno whether this can be made to work or not, though.
But this would still result (again, assuming I have it right) in
different line endings in distros depending on what OS was used to cut
the release - unless we all set up Windows boxes to cut the zip
releases and *nix boxes for the tarballs ;-)
>
> It's possible that a particular file type may have different endings
> for different files.
> For example on JMeter, the old JMX files were CRLF on Windows, but the
> new JMX files are LF on all OSes.
>
Is this specified in the svn eol props for these files?
It now occurs to me that assuming my understanding of how "eol=native"
is correct, we should be fixing crlf for non-txt files in zip distros
as well, since if these are cut using Windows, e.g. the java source
files will have CRLF line endings. So, in terms of properties, it
seems we need
maven.dist.lf.filter=**/*.java, **/*.txt, all other non-binary file
specs, i.e. all files that could have eol=native
maven.dist.crlf.filter=**/*.txt (plus whatever else we agree on)
and have the plugin do the following:
For tar.gz distributions, run fixcrlf with eol=lf and
includes=${maven.dist.lf.filter}
For zip distributions, run fixcrlf first with eol=lf and
includes=${maven.dist.lf.filter} and then again with eol=crlf and
includes=${maven.dist.crlf.filter}.
I guess another alternative would be to agree to cut all distros on
unix, maybe even using minotaur to do the release builds (I know this
would have some practical problems associated with it now). Then all
we would need is the first property, assuming we want lf line endings
everywhere else (IIRC, in the cvs days, that was the standard).
Sorry if I have misunderstood the way the svn client works or if
others view this as a non-issue. I just want to patch the plugin so
that we can get consistent distros built using maven.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
