Re: [GUMP@vmgump-vm3]: Project tomcat-trunk-validate (in module tomcat-trunk) failed

[Mark Thomas]

On 13/11/17 12:26, Konstantin Kolinko wrote:
> 2017-11-13 13:42 GMT+03:00 Mark Thomas :
>> On 13/11/17 09:49, Mark Thomas wrote:
>>
>> 
>>
>>> Hmm.
>>>
>>> As I started to look at this I realised that a large number of the
>>> classes with errors are only using the static import a few times. Some
>>> of them are using a mix of static and non-static imports.
>>>
>>> Given that switching to the non-static usage also fixes the issue, I'm
>>> going to apply that fix first and then see what is left. Generally, I
>>> plan to apply it when switching to the non-static usage results in
>>> roughly the same amount of code or less.
>>
>> Given that:
>>
>> - the majority of the test classes don't use static imports
>> - the majority of the test classes Gump is complaining about only use a
>>   few static Asserts
>> - only a small number of test classes use a large number of static
>>   Asserts
>> - global search and replace can remove all the static Assert imports
>>   quickly and easily
>> - removing static Asserts fixes the Checkstyle warnings for Gump and
>>   works with all branches
>>
>> I'm going to go with removing static Assert (and similar) imports from
>> the unit tests.
>>
> 
> Honestly, I do not like this,

Fair enough. I don't think it is perfect either.

> but this is not a technical issue, it is your itch, not worth to spend
> much time discussing.

Also agreed.

On small positive (for me at least) is that over the years I've thought
about fixing the inconsistent use of static and non-static imports in
the unit tests and this change does at least address that.

> I think this reduces code readability, may surprise newcomers. (My
> theory. One should ask a real newcomer.)

Probably for a few tests - although overall I think the difference it
makes is marginal.

> I think the trends in writing asserts are to use assertThat + Hamcrest
> library matcher, and they look better with static imports.

Agreed and agreed.

The unit tests we have now are a lot better than what we have before
(i.e. not very much) but there is definitely a lot of scope fopr
improving them, cleaning them up, reducing duplication, using better
style, increasing coverage etc.

Mark


> https://github.com/junit-team/junit4/wiki/matchers-and-assertthat
> 
> Best regards,
> Konstantin Kolinko
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [GUMP@vmgump-vm3]: Project tomcat-trunk-validate (in module tomcat-trunk) failed

[Konstantin Kolinko]

2017-11-13 13:42 GMT+03:00 Mark Thomas :
> On 13/11/17 09:49, Mark Thomas wrote:
>
> 
>
>> Hmm.
>>
>> As I started to look at this I realised that a large number of the
>> classes with errors are only using the static import a few times. Some
>> of them are using a mix of static and non-static imports.
>>
>> Given that switching to the non-static usage also fixes the issue, I'm
>> going to apply that fix first and then see what is left. Generally, I
>> plan to apply it when switching to the non-static usage results in
>> roughly the same amount of code or less.
>
> Given that:
>
> - the majority of the test classes don't use static imports
> - the majority of the test classes Gump is complaining about only use a
>   few static Asserts
> - only a small number of test classes use a large number of static
>   Asserts
> - global search and replace can remove all the static Assert imports
>   quickly and easily
> - removing static Asserts fixes the Checkstyle warnings for Gump and
>   works with all branches
>
> I'm going to go with removing static Assert (and similar) imports from
> the unit tests.
>

Honestly, I do not like this,
but this is not a technical issue, it is your itch, not worth to spend
much time discussing.

I think this reduces code readability, may surprise newcomers. (My
theory. One should ask a real newcomer.)

I think the trends in writing asserts are to use assertThat + Hamcrest
library matcher, and they look better with static imports.

https://github.com/junit-team/junit4/wiki/matchers-and-assertthat

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [GUMP@vmgump-vm3]: Project tomcat-trunk-validate (in module tomcat-trunk) failed

[Mark Thomas]

On 13/11/17 09:49, Mark Thomas wrote:



> Hmm.
> 
> As I started to look at this I realised that a large number of the
> classes with errors are only using the static import a few times. Some
> of them are using a mix of static and non-static imports.
> 
> Given that switching to the non-static usage also fixes the issue, I'm
> going to apply that fix first and then see what is left. Generally, I
> plan to apply it when switching to the non-static usage results in
> roughly the same amount of code or less.

Given that:

- the majority of the test classes don't use static imports
- the majority of the test classes Gump is complaining about only use a
  few static Asserts
- only a small number of test classes use a large number of static
  Asserts
- global search and replace can remove all the static Assert imports
  quickly and easily
- removing static Asserts fixes the Checkstyle warnings for Gump and
  works with all branches

I'm going to go with removing static Assert (and similar) imports from
the unit tests.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [GUMP@vmgump-vm3]: Project tomcat-trunk-validate (in module tomcat-trunk) failed

[Mark Thomas]

On 13/11/17 08:59, Mark Thomas wrote:
> On 11/11/17 21:47, Konstantin Kolinko wrote:
>> 2017-11-11 23:48 GMT+03:00 Mark Thomas :
>>> On 27/10/17 14:13, Mark Thomas wrote:
 Now Checkstyle 8.3 has been released, I think we need to do something
 about these. There are quite a few options.

 Do we want the minimalist approach (run Rainer's script, tweak the
 Eclipse recommendations to get as close as we can to what Checkstyle
 wants) or do we take a broader 'What was Mark thinking when he suggested
 this import order?' approach and take the opportunity to rethink the
 order (and probably choose something simpler / more standard)? Or
 something else?

 Thoughts?

 I have no strong feelings either way but I'm happy to contribute to
 whatever option we choose.
>>>
>>> Ping?
>>>
>>> I'm not sure if the lack of response is because folks are ignoring the
>>> Gump e-mails or because no-one has any strong opinions.
>>>
>>> In the absence of further feedback I plan to upgrade to Checkstyle 8.3,
>>> fix the warnings and back-port. I hope to get to this early next week.
>>
>> Beware that Checkstyle 7.0+ requires Java 8 as runtime environment.
>> Thus such upgrade cannot be easily backported to Tomcat 8.5 or earlier.
>>
>> I see the following options:
>>
>> 1) I think the easiest option is to
>> - Disable these checks at Gump (except for Tomcat trunk) and enable
>> them at Buildbot.
>>
>> Essentially, Gump bugs (regressions) in Checkstyle library and
>> notifies us about them in advance.
>> An issue is that we do not have resources to propagate these bugs to
>> Checkstyle project. (Nobody stepped up to do that).
>>
>> Buildbot will find bugs in our own project, running the version of the
>> library that we chose.
> 
> Something along those lines makes sense to me. I should be able to start
> work on that today.

Hmm.

As I started to look at this I realised that a large number of the
classes with errors are only using the static import a few times. Some
of them are using a mix of static and non-static imports.

Given that switching to the non-static usage also fixes the issue, I'm
going to apply that fix first and then see what is left. Generally, I
plan to apply it when switching to the non-static usage results in
roughly the same amount of code or less.

Mark


> 
> Mark
> 
> 
>> 2) I see that "Backport" section at Checkstyle home page [1] mentions
>> some unofficial fork of Checkstyle that can be run on Java 1.6. I have
>> not looked further.
>>
>> [1] http://checkstyle.sourceforge.net/#Backport
>>
>>
>> 3) Another idea of mine is to run all Ant builds with Java 8,
>> and explicitly configure paths to JDKs that are used for compilation.
>> In Tomcat 7 we have "java.7.home". The idea is to add explicit
>> "java.6.home" along that.
>> http://markmail.org/message/6qck3d4zqb6nh5ja
>>
>> Best regards,
>> Konstantin Kolinko
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [GUMP@vmgump-vm3]: Project tomcat-trunk-validate (in module tomcat-trunk) failed

[Mark Thomas]

On 11/11/17 21:47, Konstantin Kolinko wrote:
> 2017-11-11 23:48 GMT+03:00 Mark Thomas :
>> On 27/10/17 14:13, Mark Thomas wrote:
>>> Now Checkstyle 8.3 has been released, I think we need to do something
>>> about these. There are quite a few options.
>>>
>>> Do we want the minimalist approach (run Rainer's script, tweak the
>>> Eclipse recommendations to get as close as we can to what Checkstyle
>>> wants) or do we take a broader 'What was Mark thinking when he suggested
>>> this import order?' approach and take the opportunity to rethink the
>>> order (and probably choose something simpler / more standard)? Or
>>> something else?
>>>
>>> Thoughts?
>>>
>>> I have no strong feelings either way but I'm happy to contribute to
>>> whatever option we choose.
>>
>> Ping?
>>
>> I'm not sure if the lack of response is because folks are ignoring the
>> Gump e-mails or because no-one has any strong opinions.
>>
>> In the absence of further feedback I plan to upgrade to Checkstyle 8.3,
>> fix the warnings and back-port. I hope to get to this early next week.
> 
> Beware that Checkstyle 7.0+ requires Java 8 as runtime environment.
> Thus such upgrade cannot be easily backported to Tomcat 8.5 or earlier.
> 
> I see the following options:
> 
> 1) I think the easiest option is to
> - Disable these checks at Gump (except for Tomcat trunk) and enable
> them at Buildbot.
> 
> Essentially, Gump bugs (regressions) in Checkstyle library and
> notifies us about them in advance.
> An issue is that we do not have resources to propagate these bugs to
> Checkstyle project. (Nobody stepped up to do that).
> 
> Buildbot will find bugs in our own project, running the version of the
> library that we chose.

Something along those lines makes sense to me. I should be able to start
work on that today.

Mark


> 2) I see that "Backport" section at Checkstyle home page [1] mentions
> some unofficial fork of Checkstyle that can be run on Java 1.6. I have
> not looked further.
> 
> [1] http://checkstyle.sourceforge.net/#Backport
> 
> 
> 3) Another idea of mine is to run all Ant builds with Java 8,
> and explicitly configure paths to JDKs that are used for compilation.
> In Tomcat 7 we have "java.7.home". The idea is to add explicit
> "java.6.home" along that.
> http://markmail.org/message/6qck3d4zqb6nh5ja
> 
> Best regards,
> Konstantin Kolinko
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [GUMP@vmgump-vm3]: Project tomcat-trunk-validate (in module tomcat-trunk) failed

[Konstantin Kolinko]

2017-11-11 23:48 GMT+03:00 Mark Thomas :
> On 27/10/17 14:13, Mark Thomas wrote:
>> Now Checkstyle 8.3 has been released, I think we need to do something
>> about these. There are quite a few options.
>>
>> Do we want the minimalist approach (run Rainer's script, tweak the
>> Eclipse recommendations to get as close as we can to what Checkstyle
>> wants) or do we take a broader 'What was Mark thinking when he suggested
>> this import order?' approach and take the opportunity to rethink the
>> order (and probably choose something simpler / more standard)? Or
>> something else?
>>
>> Thoughts?
>>
>> I have no strong feelings either way but I'm happy to contribute to
>> whatever option we choose.
>
> Ping?
>
> I'm not sure if the lack of response is because folks are ignoring the
> Gump e-mails or because no-one has any strong opinions.
>
> In the absence of further feedback I plan to upgrade to Checkstyle 8.3,
> fix the warnings and back-port. I hope to get to this early next week.

Beware that Checkstyle 7.0+ requires Java 8 as runtime environment.
Thus such upgrade cannot be easily backported to Tomcat 8.5 or earlier.

I see the following options:

1) I think the easiest option is to
- Disable these checks at Gump (except for Tomcat trunk) and enable
them at Buildbot.

Essentially, Gump bugs (regressions) in Checkstyle library and
notifies us about them in advance.
An issue is that we do not have resources to propagate these bugs to
Checkstyle project. (Nobody stepped up to do that).

Buildbot will find bugs in our own project, running the version of the
library that we chose.


2) I see that "Backport" section at Checkstyle home page [1] mentions
some unofficial fork of Checkstyle that can be run on Java 1.6. I have
not looked further.

[1] http://checkstyle.sourceforge.net/#Backport


3) Another idea of mine is to run all Ant builds with Java 8,
and explicitly configure paths to JDKs that are used for compilation.
In Tomcat 7 we have "java.7.home". The idea is to add explicit
"java.6.home" along that.
http://markmail.org/message/6qck3d4zqb6nh5ja

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [GUMP@vmgump-vm3]: Project tomcat-trunk-validate (in module tomcat-trunk) failed

[Mark Thomas]

On 27/10/17 14:13, Mark Thomas wrote:
> Now Checkstyle 8.3 has been released, I think we need to do something
> about these. There are quite a few options.
> 
> Do we want the minimalist approach (run Rainer's script, tweak the
> Eclipse recommendations to get as close as we can to what Checkstyle
> wants) or do we take a broader 'What was Mark thinking when he suggested
> this import order?' approach and take the opportunity to rethink the
> order (and probably choose something simpler / more standard)? Or
> something else?
> 
> Thoughts?
> 
> I have no strong feelings either way but I'm happy to contribute to
> whatever option we choose.

Ping?

I'm not sure if the lack of response is because folks are ignoring the
Gump e-mails or because no-one has any strong opinions.

In the absence of further feedback I plan to upgrade to Checkstyle 8.3,
fix the warnings and back-port. I hope to get to this early next week.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [GUMP@vmgump-vm3]: Project tomcat-trunk-validate (in module tomcat-trunk) failed

[Mark Thomas]

Now Checkstyle 8.3 has been released, I think we need to do something
about these. There are quite a few options.

Do we want the minimalist approach (run Rainer's script, tweak the
Eclipse recommendations to get as close as we can to what Checkstyle
wants) or do we take a broader 'What was Mark thinking when he suggested
this import order?' approach and take the opportunity to rethink the
order (and probably choose something simpler / more standard)? Or
something else?

Thoughts?

I have no strong feelings either way but I'm happy to contribute to
whatever option we choose.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [GUMP@vmgump-vm3]: Project tomcat-trunk-validate (in module tomcat-trunk) failed

[Rainer Jung]

Am 25.09.2017 um 21:43 schrieb Mark Thomas:

On 24/09/17 12:12, Konstantin Kolinko wrote:

2017-09-24 12:45 GMT+03:00 Rainer Jung :

The current Gump failures during validate might be due to the following
change in checkstyle:

https://github.com/checkstyle/checkstyle/issues/5065

Gump uses a snapshot of checkstyle.

The complains should be mostly about additional separator lines e.g. between
static and non-static imports from the same packages. Example:

...
import static org.junit.Assert.assertEquals;

import org.junit.Test;
...

OK, if I clean those up? Or do we want to keep our formatting here?


I am OK to clean those, but I think checkstyle is wrong here.

Maybe there is a way to explicitly configure relative order of
"static" vs "non-static" imports in the same code (e.g. as separate
explicit groups). Which of those must be ordered first ("import static
org.junit" or "import org.junit") is debatable.


I'd be +1 to anything that Checkstyle and Eclipse can agree on.

Mark


Since I started this discussion: I am not aware on how to achieve this. 
At least Checkstyle seems to not have an option to support our current 
style, namely static imports directly before their import group but 
separated from it. It only supports static imports above or beneath 
everything else in a separate group, or static imports as part of the 
respective group but optionally at its start or end. The check for 
spurious separating lines between static and non-static imports is the 
new feature in the Checkstyle snapshot.


I do not know, whether eclipse supports dropping that separating line.

I do have a little script to remove those lines, so once we want to 
reformat, I can do that without much work.


Regards,

Rainer



Also this is related to configuration instructions in
\res\ide-support\eclipse\java-compiler-errors-warnings.txt

[[[
# Java -> Code Style -> Organize Imports
==

The following configuration of "Organize Imports" setting can be
recommended for a quick setup. The order is enforced by checkstyle, so for
the authoritative definition look at  in
res/checkstyle/checkstyle.xml

  - java
  - javax
  - async
  - jsp2
  - [static] org.junit
  - org.junit
  - [static] org
  - org
  - com
  - util
]]]

With the above configuration "Organize Imports" command in Eclipse
places static and non-static imports into separate groups.



Am 24.09.2017 um 01:15 schrieb Bill Barker:


To whom it may engage...
  This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.

Project tomcat-trunk-validate has an issue affecting its community
integration.
This issue affects 1 projects,
   and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
  - tomcat-trunk-validate :  Tomcat 9.x, a web server implementing the
Java Servlet 4.0,
...


Full details are available at:

http://vmgump-vm3.apache.org/tomcat-trunk/tomcat-trunk-validate/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages)
were provided:
   -DEBUG- Dependency on checkstyle exists, no need to add for property
checkstyle.jar.
   -INFO- Failed with reason build failed



The following work was performed:

http://vmgump-vm3.apache.org/tomcat-trunk/tomcat-trunk-validate/gump_work/build_tomcat-trunk_tomcat-trunk-validate.html
Work Name: build_tomcat-trunk_tomcat-trunk-validate (Type: Build)
Work ended in a state of : Failed
Elapsed: 37 secs
Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true
-Dbuild.sysclasspath=only org.apache.tools.ant.Main
-Dgump.merge=/srv/gump/public/gump/work/merge.xml
-Dbase.path=/srv/gump/public/workspace/tomcat-trunk/tomcat-build-libs
-Dcheckstyle.jar=/srv/gump/public/workspace/checkstyle/target/checkstyle-8.3-SNAPSHOT.jar
-Dexecute.validate=true validate
[Working Directory: /srv/gump/public/workspace/tomcat-trunk]
CLASSPATH:

Re: [GUMP@vmgump-vm3]: Project tomcat-trunk-validate (in module tomcat-trunk) failed

[Mark Thomas]

On 24/09/17 12:12, Konstantin Kolinko wrote:
> 2017-09-24 12:45 GMT+03:00 Rainer Jung :
>> The current Gump failures during validate might be due to the following
>> change in checkstyle:
>>
>> https://github.com/checkstyle/checkstyle/issues/5065
>>
>> Gump uses a snapshot of checkstyle.
>>
>> The complains should be mostly about additional separator lines e.g. between
>> static and non-static imports from the same packages. Example:
>>
>> ...
>> import static org.junit.Assert.assertEquals;
>>
>> import org.junit.Test;
>> ...
>>
>> OK, if I clean those up? Or do we want to keep our formatting here?
> 
> I am OK to clean those, but I think checkstyle is wrong here.
> 
> Maybe there is a way to explicitly configure relative order of
> "static" vs "non-static" imports in the same code (e.g. as separate
> explicit groups). Which of those must be ordered first ("import static
> org.junit" or "import org.junit") is debatable.

I'd be +1 to anything that Checkstyle and Eclipse can agree on.

Mark


> 
> Also this is related to configuration instructions in
> \res\ide-support\eclipse\java-compiler-errors-warnings.txt
> 
> [[[
> # Java -> Code Style -> Organize Imports
> ==
> 
> The following configuration of "Organize Imports" setting can be
> recommended for a quick setup. The order is enforced by checkstyle, so for
> the authoritative definition look at  in
> res/checkstyle/checkstyle.xml
> 
>  - java
>  - javax
>  - async
>  - jsp2
>  - [static] org.junit
>  - org.junit
>  - [static] org
>  - org
>  - com
>  - util
> ]]]
> 
> With the above configuration "Organize Imports" command in Eclipse
> places static and non-static imports into separate groups.
> 
> 
>> Am 24.09.2017 um 01:15 schrieb Bill Barker:
>>>
>>> To whom it may engage...
>>>  This is an automated request, but not an unsolicited one. For
>>> more information please visit http://gump.apache.org/nagged.html,
>>> and/or contact the folk at gene...@gump.apache.org.
>>>
>>> Project tomcat-trunk-validate has an issue affecting its community
>>> integration.
>>> This issue affects 1 projects,
>>>   and has been outstanding for 11 runs.
>>> The current state of this project is 'Failed', with reason 'Build Failed'.
>>> For reference only, the following projects are affected by this:
>>>  - tomcat-trunk-validate :  Tomcat 9.x, a web server implementing the
>>> Java Servlet 4.0,
>>> ...
>>>
>>>
>>> Full details are available at:
>>>
>>> http://vmgump-vm3.apache.org/tomcat-trunk/tomcat-trunk-validate/index.html
>>>
>>> That said, some information snippets are provided here.
>>>
>>> The following annotations (debug/informational/warning/error messages)
>>> were provided:
>>>   -DEBUG- Dependency on checkstyle exists, no need to add for property
>>> checkstyle.jar.
>>>   -INFO- Failed with reason build failed
>>>
>>>
>>>
>>> The following work was performed:
>>>
>>> http://vmgump-vm3.apache.org/tomcat-trunk/tomcat-trunk-validate/gump_work/build_tomcat-trunk_tomcat-trunk-validate.html
>>> Work Name: build_tomcat-trunk_tomcat-trunk-validate (Type: Build)
>>> Work ended in a state of : Failed
>>> Elapsed: 37 secs
>>> Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true
>>> -Dbuild.sysclasspath=only org.apache.tools.ant.Main
>>> -Dgump.merge=/srv/gump/public/gump/work/merge.xml
>>> -Dbase.path=/srv/gump/public/workspace/tomcat-trunk/tomcat-build-libs
>>> -Dcheckstyle.jar=/srv/gump/public/workspace/checkstyle/target/checkstyle-8.3-SNAPSHOT.jar
>>> -Dexecute.validate=true validate
>>> [Working Directory: /srv/gump/public/workspace/tomcat-trunk]
>>> CLASSPATH:
>>> /usr/lib/jvm/java-8-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/checkstyle/target/checkstyle-8.3-SNAPSHOT.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-20170924.jar:/srv/gump/packages/commons-collections3/commons-collections-3.2.1.jar:/srv/gump/public/workspace/commons-cli/target/commons-cli-1.5-SNAPSHOT.jar:/srv/gump/public/workspace/commons-lang-trunk/target/commons-lang3-3.7-SNAPSHOT.jar:/srv/g
>>>
>>> ump/public/workspace/apache-commons/logging/target/commons-logging-20170924.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-20170924.jar:/srv/gump/public/workspace/google-guava/guava/target/guava-24.0-jre-SNAPSHOT.jar
>>> -
>>> [checkstyle] [ERROR]
>>> 

Re: [GUMP@vmgump-vm3]: Project tomcat-trunk-validate (in module tomcat-trunk) failed

[Konstantin Kolinko]

2017-09-24 12:45 GMT+03:00 Rainer Jung :
> The current Gump failures during validate might be due to the following
> change in checkstyle:
>
> https://github.com/checkstyle/checkstyle/issues/5065
>
> Gump uses a snapshot of checkstyle.
>
> The complains should be mostly about additional separator lines e.g. between
> static and non-static imports from the same packages. Example:
>
> ...
> import static org.junit.Assert.assertEquals;
>
> import org.junit.Test;
> ...
>
> OK, if I clean those up? Or do we want to keep our formatting here?

I am OK to clean those, but I think checkstyle is wrong here.

Maybe there is a way to explicitly configure relative order of
"static" vs "non-static" imports in the same code (e.g. as separate
explicit groups). Which of those must be ordered first ("import static
org.junit" or "import org.junit") is debatable.

Also this is related to configuration instructions in
\res\ide-support\eclipse\java-compiler-errors-warnings.txt

[[[
# Java -> Code Style -> Organize Imports
==

The following configuration of "Organize Imports" setting can be
recommended for a quick setup. The order is enforced by checkstyle, so for
the authoritative definition look at  in
res/checkstyle/checkstyle.xml

 - java
 - javax
 - async
 - jsp2
 - [static] org.junit
 - org.junit
 - [static] org
 - org
 - com
 - util
]]]

With the above configuration "Organize Imports" command in Eclipse
places static and non-static imports into separate groups.


> Am 24.09.2017 um 01:15 schrieb Bill Barker:
>>
>> To whom it may engage...
>>  This is an automated request, but not an unsolicited one. For
>> more information please visit http://gump.apache.org/nagged.html,
>> and/or contact the folk at gene...@gump.apache.org.
>>
>> Project tomcat-trunk-validate has an issue affecting its community
>> integration.
>> This issue affects 1 projects,
>>   and has been outstanding for 11 runs.
>> The current state of this project is 'Failed', with reason 'Build Failed'.
>> For reference only, the following projects are affected by this:
>>  - tomcat-trunk-validate :  Tomcat 9.x, a web server implementing the
>> Java Servlet 4.0,
>> ...
>>
>>
>> Full details are available at:
>>
>> http://vmgump-vm3.apache.org/tomcat-trunk/tomcat-trunk-validate/index.html
>>
>> That said, some information snippets are provided here.
>>
>> The following annotations (debug/informational/warning/error messages)
>> were provided:
>>   -DEBUG- Dependency on checkstyle exists, no need to add for property
>> checkstyle.jar.
>>   -INFO- Failed with reason build failed
>>
>>
>>
>> The following work was performed:
>>
>> http://vmgump-vm3.apache.org/tomcat-trunk/tomcat-trunk-validate/gump_work/build_tomcat-trunk_tomcat-trunk-validate.html
>> Work Name: build_tomcat-trunk_tomcat-trunk-validate (Type: Build)
>> Work ended in a state of : Failed
>> Elapsed: 37 secs
>> Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true
>> -Dbuild.sysclasspath=only org.apache.tools.ant.Main
>> -Dgump.merge=/srv/gump/public/gump/work/merge.xml
>> -Dbase.path=/srv/gump/public/workspace/tomcat-trunk/tomcat-build-libs
>> -Dcheckstyle.jar=/srv/gump/public/workspace/checkstyle/target/checkstyle-8.3-SNAPSHOT.jar
>> -Dexecute.validate=true validate
>> [Working Directory: /srv/gump/public/workspace/tomcat-trunk]
>> CLASSPATH:
>> /usr/lib/jvm/java-8-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/checkstyle/target/checkstyle-8.3-SNAPSHOT.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-20170924.jar:/srv/gump/packages/commons-collections3/commons-collections-3.2.1.jar:/srv/gump/public/workspace/commons-cli/target/commons-cli-1.5-SNAPSHOT.jar:/srv/gump/public/workspace/commons-lang-trunk/target/commons-lang3-3.7-SNAPSHOT.jar:/srv/g
>>
>> ump/public/workspace/apache-commons/logging/target/commons-logging-20170924.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-20170924.jar:/srv/gump/public/workspace/google-guava/guava/target/guava-24.0-jre-SNAPSHOT.jar
>> -
>> [checkstyle] [ERROR]
>> /srv/gump/public/workspace/tomcat-trunk/test/org/apache/el/TestValueExpressionImpl.java:34:
>> Extra separation in import group before 'org.junit.Test' [ImportOrder]
>> [checkstyle] [ERROR]
>> 

Re: [GUMP@vmgump-vm3]: Project tomcat-trunk-validate (in module tomcat-trunk) failed

[Rainer Jung]

The current Gump failures during validate might be due to the following 
change in checkstyle:


https://github.com/checkstyle/checkstyle/issues/5065

Gump uses a snapshot of checkstyle.

The complains should be mostly about additional separator lines e.g. 
between static and non-static imports from the same packages. Example:


...
import static org.junit.Assert.assertEquals;

import org.junit.Test;
...

OK, if I clean those up? Or do we want to keep our formatting here?

Regards,

Rainer

Am 24.09.2017 um 01:15 schrieb Bill Barker:

To whom it may engage...
 
This is an automated request, but not an unsolicited one. For

more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.

Project tomcat-trunk-validate has an issue affecting its community integration.
This issue affects 1 projects,
  and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
 - tomcat-trunk-validate :  Tomcat 9.x, a web server implementing the Java 
Servlet 4.0,
...


Full details are available at:
 http://vmgump-vm3.apache.org/tomcat-trunk/tomcat-trunk-validate/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
  -DEBUG- Dependency on checkstyle exists, no need to add for property 
checkstyle.jar.
  -INFO- Failed with reason build failed



The following work was performed:
http://vmgump-vm3.apache.org/tomcat-trunk/tomcat-trunk-validate/gump_work/build_tomcat-trunk_tomcat-trunk-validate.html
Work Name: build_tomcat-trunk_tomcat-trunk-validate (Type: Build)
Work ended in a state of : Failed
Elapsed: 37 secs
Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only org.apache.tools.ant.Main 
-Dgump.merge=/srv/gump/public/gump/work/merge.xml 
-Dbase.path=/srv/gump/public/workspace/tomcat-trunk/tomcat-build-libs 
-Dcheckstyle.jar=/srv/gump/public/workspace/checkstyle/target/checkstyle-8.3-SNAPSHOT.jar
 -Dexecute.validate=true validate
[Working Directory: /srv/gump/public/workspace/tomcat-trunk]
CLASSPATH: 
/usr/lib/jvm/java-8-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/checkstyle/target/checkstyle-8.3-SNAPSHOT.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-20170924.jar:/srv/gump/packages/commons-collections3/commons-collections-3.2.1.jar:/srv/gump/public/workspace/commons-cli/target/commons-cli-1.5-SNAPSHOT.jar:/srv/gump/public/workspace/commons-lang-trunk/target/commons-lang3-3.7-SNAPSHOT.jar:/srv/g
  
ump/public/workspace/apache-commons/logging/target/commons-logging-20170924.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-20170924.jar:/srv/gump/public/workspace/google-guava/guava/target/guava-24.0-jre-SNAPSHOT.jar
-
[checkstyle] [ERROR] 
/srv/gump/public/workspace/tomcat-trunk/test/org/apache/el/TestValueExpressionImpl.java:34:
 Extra separation in import group before 'org.junit.Test' [ImportOrder]
[checkstyle] [ERROR] 
/srv/gump/public/workspace/tomcat-trunk/test/org/apache/el/lang/TestELArithmetic.java:26:
 Extra separation in import group before 'org.junit.Assert' [ImportOrder]
[checkstyle] [ERROR] 
/srv/gump/public/workspace/tomcat-trunk/test/org/apache/el/lang/TestELSupport.java:30:
 Extra separation in import group before 'org.junit.Assert' [ImportOrder]
[checkstyle] [ERROR] 
/srv/gump/public/workspace/tomcat-trunk/test/org/apache/el/parser/TestELParser.java:30:
 Extra separation in import group before 'org.junit.Ignore' [ImportOrder]
[checkstyle] [ERROR] 
/srv/gump/public/workspace/tomcat-trunk/test/org/apache/jasper/compiler/TestAttributeParser.java:24:
 Extra separation in import group before 'org.junit.Test' [ImportOrder]
[checkstyle] [ERROR] 
/srv/gump/public/workspace/tomcat-trunk/test/org/apache/jasper/compiler/TestCompiler.java:29:
 Extra separation in import group before 'org.junit.Test' [ImportOrder]
[checkstyle] [ERROR] 
/srv/gump/public/workspace/tomcat-trunk/test/org/apache/jasper/compiler/TestGenerator.java:36:
 Extra separation in import group before 'org.junit.Assert' [ImportOrder]
[checkstyle] [ERROR] 
/srv/gump/public/workspace/tomcat-trunk/test/org/apache/jasper/compiler/TestJspConfig.java:24:
 Extra separation in 

Re: [GUMP@vmgump-vm3]: Project tomcat-trunk-validate (in module tomcat-trunk) failed

[Rémy Maucherat]

On Thu, Jul 27, 2017 at 3:41 AM, Bill Barker  wrote:

> validate:
> [mkdir] Created dir: /srv/gump/public/workspace/
> tomcat-trunk/output/res/checkstyle
> [checkstyle] Running Checkstyle 8.2-SNAPSHOT on 3152 files
> [checkstyle] Running Checkstyle 8.2-SNAPSHOT on 245 files
> [checkstyle] Running Checkstyle 8.2-SNAPSHOT on 1351 files
> [checkstyle] [ERROR] /srv/gump/public/workspace/
> tomcat-trunk/java/org/apache/tomcat/util/digester/Digester.java:40:1:
> Disallowed import - org.apache.catalina.Lifecycle. [ImportControl]
> [checkstyle] [ERROR] /srv/gump/public/workspace/
> tomcat-trunk/java/org/apache/tomcat/util/digester/Digester.java:41:1:
> Disallowed import - org.apache.catalina.LifecycleEvent. [ImportControl]
> [checkstyle] [ERROR] /srv/gump/public/workspace/
> tomcat-trunk/java/org/apache/tomcat/util/digester/Digester.java:42:1:
> Disallowed import - org.apache.catalina.LifecycleListener. [ImportControl]
>
> Unfortunately my change creates a circular dependency. I don't really see
a good way to do it without this, so I guess the best way is to revert.

Rémy