Am 23.06.2017 um 17:24 schrieb Allon Mureinik:
> On Fri, Jun 23, 2017 at 6:03 PM, Oliver Heger
> wrote:
>
>>
>>
>> Am 23.06.2017 um 08:58 schrieb Allon Mureinik:
>>> The root cause, IMHO, is having failValidation=false configured in the
>>> pom.xml. This way, when
On Jun 24, 2017 12:31 PM, "Oliver Heger"
wrote:
Should changes related to the setup and handling of checkstyle then be
done for Commons as a whole?
(No P.S.)
It is the sort of thing fits nearly I a parent. Maven is one example (not
sure how much customization is
On 25 June 2017 at 10:09, Claude Warren wrote:
> Eclipse lets you export the format rules as separate files. My suggestion
> was intended to mean that these files should be included, not the entire
> .settings as that contains a number of local settings and my leak
>
Eclipse lets you export the format rules as separate files. My suggestion
was intended to mean that these files should be included, not the entire
.settings as that contains a number of local settings and my leak
confidential information. (I have not verified that it will leak
confidential
Should changes related to the setup and handling of checkstyle then be
done for Commons as a whole?
Oliver
(No P.S.)
Am 23.06.2017 um 21:19 schrieb Gary Gregory:
> I
>
> P.S.
>
> Agree
>
> P.P.S.
>
> With
>
> P.P.P.S.
>
> you!
>
> Gary
>
> On Jun 23, 2017 10:28, "Simon Spero"
I
P.S.
Agree
P.P.S.
With
P.P.P.S.
you!
Gary
On Jun 23, 2017 10:28, "Simon Spero" wrote:
> On Jun 23, 2017 11:03 AM, "Oliver Heger"
> wrote:
>
> However, letting the build fail because of checkstyle error is too
> restrictive IMHO. My
On Jun 23, 2017 11:03 AM, "Oliver Heger"
wrote:
However, letting the build fail because of checkstyle error is too
restrictive IMHO. My approach is to work through the errors before creating
a new release. This has the disadvantage that errors might accumulate; but
On Fri, Jun 23, 2017 at 9:35 AM, sebb wrote:
> On 23 June 2017 at 17:29, Gary Gregory wrote:
> > On Fri, Jun 23, 2017 at 8:21 AM, Claude Warren wrote:
> >
> >> How about an eclipse format configuration that will correct the error on
>
Instead of a per-IDE specific file, it may be useful to look into
EditorConfig [1]. A lot of IDEs support it either natively or via plugin,
and it may help having to replicate the same styling "logic" per IDE.
[1] http://editorconfig.org/
On Fri, Jun 23, 2017 at 7:35 PM, sebb
On 23 June 2017 at 17:29, Gary Gregory wrote:
> On Fri, Jun 23, 2017 at 8:21 AM, Claude Warren wrote:
>
>> How about an eclipse format configuration that will correct the error on
>> demand. Granted you have to run eclipse but if such a file were
On Fri, Jun 23, 2017 at 8:24 AM, Allon Mureinik wrote:
> On Fri, Jun 23, 2017 at 6:03 PM, Oliver Heger <
> oliver.he...@oliver-heger.de>
> wrote:
>
> >
> >
> > Am 23.06.2017 um 08:58 schrieb Allon Mureinik:
> > > The root cause, IMHO, is having failValidation=false configured
On Fri, Jun 23, 2017 at 8:21 AM, Claude Warren wrote:
> How about an eclipse format configuration that will correct the error on
> demand. Granted you have to run eclipse but if such a file were created
> (and checked in) then it would be easy for anyone running eclipse to fix
On Fri, Jun 23, 2017 at 6:03 PM, Oliver Heger
wrote:
>
>
> Am 23.06.2017 um 08:58 schrieb Allon Mureinik:
> > The root cause, IMHO, is having failValidation=false configured in the
> > pom.xml. This way, when you introduce a new problem your only option to
> >
How about an eclipse format configuration that will correct the error on
demand. Granted you have to run eclipse but if such a file were created
(and checked in) then it would be easy for anyone running eclipse to fix it.
Claude
On Fri, Jun 23, 2017 at 4:03 PM, Oliver Heger
Am 23.06.2017 um 08:58 schrieb Allon Mureinik:
> The root cause, IMHO, is having failValidation=false configured in the
> pom.xml. This way, when you introduce a new problem your only option to
> notice it is if you visually scan mvn's output. As evident by the current
> state of the build, not
The root cause, IMHO, is having failValidation=false configured in the
pom.xml. This way, when you introduce a new problem your only option to
notice it is if you visually scan mvn's output. As evident by the current
state of the build, not everyone notices these.
A more robust approach would be
FYI, to whom can take the time to fix this.
When I run 'mvn clean install', I get:
[INFO] --- maven-checkstyle-plugin:2.15:check (default) @
commons-configuration2 ---
[INFO] There are 23 errors reported by Checkstyle 6.1.1 with
17 matches
Mail list logo