Il mer 24 lug 2019, 10:02 Tibor Digana ha scritto:
> Hi Enrico,
>
> Do we have a statement from vendors of PMD and/or Checkstyle libraries that
> their rules would turn to platform independence?
> I know there was a pull request on GitHub and a promis with the release (I
> guess PMD).
> Once we
Hi Enrico,
Do we have a statement from vendors of PMD and/or Checkstyle libraries that
their rules would turn to platform independence?
I know there was a pull request on GitHub and a promis with the release (I
guess PMD).
Once we would have these libraries with modified default values in favor
Robert> According to the ASF the -sources.zip are the official release, not
the git tag
That's right
Robert>In this case you don't control the EOL, it is based on the OS of the
release manager.
Is it? I would disagree here.
For instance, Apache JMeter produces both -src.zip (CRLF), and
Keep in mind there's another important situation that you can't control it like
this.
According to the ASF the -sources.zip are the official release, not the git
tag. This means that you should unpack the zip and be able to verify it on all
OSes.
In this case you don't control the EOL, it is
Ah, thanks Vladimir, that's even better. I was not 100% sure it would be
possible to retain complete control over resulting line endings for those
files, regardless of user git settings of stuff like autocrlf = true and
whatnot, but it seems there is, that's great news. Thanks!
- Eric L
On Thu,
Eric>In that case, we should generate the test files (to
Eric>avoid git interfering), one with linux-style EOLs and one with
Eric>Windows-style EOLs and test with both.
You'd better have those files under Git control, and you could just specify
.gitattributes so the LF file is always LF, and CRLF
Hi Enrico!
If I remember correctly, a number of weeks ago I tried using Checkstyle
8.21 with maven-checkstyle-plugin (I had simply cloned the
maven-checkstyle-plugin repository) and it did solve the problem with the
test case discussed in this thread. However, as I recall there was another,
Just in case: I see you seem to be battling against CRLF
For instance: https://github.com/apache/maven-checkstyle-plugin/pull/16
Did you consider to add the relevant .gitattributes file to ensure Git
converts the files automatically?
With a proper .gitattributes file, it is just impossible to
Il mer 17 lug 2019, 13:28 Eric Lilja ha scritto:
> I believe, if we instead upgrade to Checkstyle 8.21 or later, we don't need
> to do any of those alternative approaches.
>
> https://github.com/checkstyle/checkstyle/issues/4073
Eric
I think it is the best idea
Do you have cycles to give it a
I believe, if we instead upgrade to Checkstyle 8.21 or later, we don't need
to do any of those alternative approaches.
https://github.com/checkstyle/checkstyle/issues/4073
- Eric L
On Wed, Jul 17, 2019 at 1:20 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> Robert>A clone from
Robert>A clone from Git succeeds, but the sources.zip fails.
Robert>The files in the zip are generated on a unix system, so all EOLs in
text files are LF
Robert>...
Robert>The fix: add a setup.groovy to the IT and rewrite the java files
with OS specific EOLs
Alternative approaches:
A) Provide
Yeah, sounds like a good idea to take full control of the line breaks in
files, if they should be used to test line-break related features, since
git might convert them on certain platforms if configured to do so (I tend
to use Cygwin's git so I personally get unix-style line breaks). Looking
Il lun 27 mag 2019, 22:27 Eric Lilja ha scritto:
> I mean that we don't need to convert any line breaks in any files in
> maven-checkstyle-plugin for the ITs to work, if we use checkstyle 8.21.
> However, we could extend the tests for "file-ends-with-newline" to
> explicitly cover all valid
I mean that we don't need to convert any line breaks in any files in
maven-checkstyle-plugin for the ITs to work, if we use checkstyle 8.21.
However, we could extend the tests for "file-ends-with-newline" to
explicitly cover all valid combinations of
system-line-break/file-line-break. Like if my
Hi Enrico! Just out of curiosity, what do you mean by " We are also fixing
EOL in the checkstyle plugin code base"? No change in the plugin is
required with regards to EOLs to make tests pass, simply bump to version
8.21 of checkstyle itself (but there were two other errors, seemingly not
related
Eric
Thank you
We are also fixing EOL in the checkstyle plugin code base
Enrico
Il lun 27 mag 2019, 11:34 Eric Lilja ha scritto:
> Just to inform you that this problem has been resolved in version 8.21 of
> checkstyle, which was just released, and I've confirmed the fix works by
> running
Just to inform you that this problem has been resolved in version 8.21 of
checkstyle, which was just released, and I've confirmed the fix works by
running the ITs on the checkstyle-plugin (checked out master on Cygwin).
There are two other failures, though (was one failure with 8.20 if I recall
Enrico, I checked the Checkstyle rules again (default value = system) and
Robert is right, please adjust the IT sources on the fly.
Not sure why INFRA or Jenkins sets the Windows EOL to LF.
Therefore we could not find this issue in version 3.0.0 (Jan 04) because
the IT was created on Jan 17 and we
Robert, see this https://issues.apache.org/jira/browse/MCHECKSTYLE-376
The Git clone fails on Windows. Most probably our Jenkins is using LF EOL
on Windows and not CRLF.
We cannot hack Java files only to pass the IT.
Why one or two ITs failed and the other dont.
The IT has only one POM and two
FYI, I'm on Windows (by default), just cmdline, so no powercommand or gitbash
or similar prompts.
A clone from Git succeeds, but the sources.zip fails.
The files in the zip are generated on a unix system, so all EOLs in text files
are LF
If I replace the EOL from unix to Windows the build
Il mer 15 mag 2019, 17:44 Tibor Digana ha scritto:
> @Enrico did you announce the Checkstyle team about our issue [1]?
> What is going on with that?
> [1]: https://issues.apache.org/jira/browse/MCHECKSTYLE-376
> Thx
> Tibor17
>
Not yet sorry. I have been busy today. Will do this evening
@Enrico did you announce the Checkstyle team about our issue [1]?
What is going on with that?
[1]: https://issues.apache.org/jira/browse/MCHECKSTYLE-376
Thx
Tibor17
On Tue, May 14, 2019 at 2:11 PM Enrico Olivelli wrote:
> I will get a windows box and try to reproduce.
> It is weird that on ASF
Thanks
I am able to reproduce the issue on a Windows box.
Still I can't understand why we aren't seeing problems on CI.
Eric,
do you have cycles to create a JIRA and send a Pull request ?
We can fix it in master.
As Tibor said, I think this is not a blocker for the 3.1.0 release.
Otherwise I
Il giorno mar 14 mag 2019 alle ore 14:34 Tibor Digana <
tibordig...@apache.org> ha scritto:
> Two files in one IT are problematic but I don't think it is a problem for
> your release.
> The CPD should be fixed and a method should be reused but again it is not
> a reason to interrupt the vote.
>
Since git settings may influence line separators when cloning and
Checkstyle seems to want read line separator to match System.lineSeparator,
maybe the test need to take full control back (from git) over the two files
in the test, to have a fully deterministic test input files.
- Eric L
On Tue,
Hi, I edited the wrong files before when I changed line breaks (edited
copies under target folder, silly me!). I changed the line separators to
Windows-style for the two files under MCHECKSTYLE-54 (Mcheckstyle54.java
and package.info) and the integration tests passes (expect for that other
I wrote both files again, see the attachments (windows and Unix EOL).
To be faster, I am running the command *mvn checkstyle:check* from the (IT
target) path on my system
c:\vcs\github\maven-checkstyle-plugin\target\it\MCHECKSTYLE-54\src\main\java\org\apache\maven\plugins\checkstyle\mcheckstyle54\
Two files in one IT are problematic but I don't think it is a problem for
your release.
The CPD should be fixed and a method should be reused but again it is not
a reason to interrupt the vote.
One more question. Why did you "git push" the history from Maven Release
plugin?
This should be done
28 matches
Mail list logo
