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]

Reply via email to