On 27/11/05, Phil Steitz <[EMAIL PROTECTED]> wrote: > <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
Agreed. But we are talking about different contents for the zip and tar.gz releases. > 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 ;-) Hopefully not - I assumed that the maven/ant task would change the line-endings as needed, so as to create an archive that was the same as if it had been created on an OS with a different native setting. That's why it needs to know what SVN has done. > > > > 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? Yes (or it should be). > 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 I assume you mean files with an extension that is not ".txt" here ... > 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}. If one can use svn:eol-type, then this can all be automated, as the eol-type will determine whether or not the line endings have been changed by SVN. > 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. And Ant, ideally. > Phil > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]