Things in a POM file that are not probably incorrect

[Simon Spero]

1.5
1.5
org.apache.commons.functor

JDK 9 cannot generate or parse class files compiled with -target 1.5  [1].

Per the JPMS Armistice talks,   "Automatic-Module-Name" header should only
be added to jars that have been tested under JDK 9 [2].

Also, javac now supports the new "--release" argument as an alternative to
source + target.
Roughly speaking, this option combines -source & -target with a little bit
of animal sniffing.  JDK 9 includes  signatures for JDK 6,7,8, and 9 (i.e.
all the releases which jdk9 can compile for).
This option is supported by maven-compiler-plugin [4] via a 
element in the plugin  configuration, or by settting the property
*maven.compiler.release* .

Simon

[1] https://bugs.openjdk.java.net/browse/JDK-8011044
[2]
http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05-18#AutomaticModuleNames--ModuleNameInManifest
[3] http://openjdk.java.net/jeps/247
[4]
https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#release

Re: [FUNCTOR] Why do we have an API module?

[Simon Spero]

On Jun 25, 2017 5:54 AM, "Benedikt Ritter"  wrote:

Hi,

> Am 24.06.2017 um 20:19 schrieb Matt Benson :
>
> TBH, I don't know that I think there's a reason to do such a
library unless it's really a game changer.

Currently functor is somehow in limbo state. It has been promoted to
proper, but there has never been a release. So I wonder what we want to do
with it.


I think Matt has the right of it.

If there's no current need for Functor, and it's never had a  release, does
it need to make a sound?

A lot of the current snapshot is redundant under plain old JDK 8;  much of
the rest is subsumed by various functional and/or reactive libraries (of
which there are quite a few).  AOL's Cyclops [1] bridges a bunch of these
(e.g. [2],[3].[4]). Is there anything that isn't provided for in cyclops or
one of the things it bridges?

Simon

[1] https://github.com/aol/cyclops-react/wiki
[2] https://www.vavr.io/vavr-docs/
[3] https://github.com/jOOQ/jOOL
[4] https://github.com/reactivex/rxjava

Re: [configuration] checkstyle fails build

[Oliver Heger]

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 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 to set failValidation=true, and actively
>>> fail the build if checkstyle's rules are violated.
>>>
>>> I've submitted a PR to fix all the existing issues and enable this
>>> validation. Reviews are welcome:
>>> https://github.com/apache/commons-configuration/pull/5
>>>
>>
>> Thanks for the PR, I will have a look.
>>
>> 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 from one release to the next one there is typically not
>> that much.
>>
>> Oliver
>>
> 
> This is ultimately a matter of taste, but let me try to explain this point
> of view better.
> The baseline is that the project should pass checkstyle with no issues (the
> first three patches in this PR will get us there).
> 
> From that point on, the goal is not accept any patch that would break the
> styling.
> Think of it way - If you were reviewing a patch that didn't comply to the
> project's style, you'd comment about it and ask the author to fix it before
> merging.
> Having checkstyle do this *as part of the CI* has the same effect, but it
> takes some responsibility off the maintainers' shoulders.
> First, contributers can easily see if they need to improve their patch by
> running mvn install (arguably, they could do this even without enabling
> checkstyle validations, but it makes it much easier to notice). Second, and
> more importantly, it allows the CI to block such patches, so maintainers
> can decide whether to reject them (or even fix them themselves, if they are
> so inclined) so that checking checkstyle before the release becomes a
> non-issue - it just always passes.
> 
> 
The fixes for checkstyle issues have been applied. Many thanks again.

Regarding the change of the checkstyle failure behavior, I prefer
waiting for a more global decision.

Oliver

> 
>>
>>>
>>> On Thu, Jun 22, 2017 at 11:10 PM, Gary Gregory 
>>> wrote:
>>>
 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
 C:\vcs\svn\apache\commons\trunks-proper\configuration/conf/
>> checkstyle.xml
 ruleset.
 [ERROR]
 src\main\java\org\apache\commons\configuration2\
 AbstractHierarchicalConfiguration.java[976]
 (regexp) RegexpSingleline: Line has trailing spaces.
 [ERROR]
 src\main\java\org\apache\commons\configuration2\
 AbstractHierarchicalConfiguration.java[978:30]
 (blocks) LeftCurly: '{' should be on a new line.
 [ERROR]
 src\main\java\org\apache\commons\configuration2\
 AbstractYAMLBasedConfiguration.java[0]
 (misc) NewlineAtEndOfFile: File does not end with a newline.
 [ERROR]
 src\main\java\org\apache\commons\configuration2\builder\fluent\
 INIBuilderParameters.java[0]
 (misc) NewlineAtEndOfFile: File does not end with a newline.
 [ERROR]
 src\main\java\org\apache\commons\configuration2\builder\
 INIBuilderParametersImpl.java[0]
 (misc) NewlineAtEndOfFile: File does not end with a newline.
 [ERROR]
 src\main\java\org\apache\commons\configuration2\builder\
 INIBuilderParametersImpl.java[42:5]
 (whitespace) FileTabCharacter: File contains tab characters (this is the
 first instance).
 [ERROR]
 src\main\java\org\apache\commons\configuration2\builder\
 INIBuilderParametersImpl.java[52:84]
 (blocks) LeftCurly: '{' should be on a new line.
 [ERROR]
 src\main\java\org\apache\commons\configuration2\
 builder\INIBuilderProperties.java[0]
 (misc) NewlineAtEndOfFile: File does not end with a newline.
 [ERROR]
 src\main\java\org\apache\commons\configuration2\ex\
 ConfigurationRuntimeException.java[68]
 (regexp) RegexpSingleline: Line has trailing spaces.
 [ERROR]
 src\main\java\org\apache\commons\configuration2\JSONConfigur
>> ation.java[0]
 (misc) NewlineAtEndOfFile: File does not end with a newline.
 [ERROR]
 src\main\java\org\apache\commons\configuration2\
 JSONConfiguration.java[43:5]
 (javadoc) JavadocVariable: Missing a Javadoc comment.
 [ERROR]
 src\main\java\org\apache\commons\configuration2\
 JSONConfiguration.java[44:5]
 (javadoc) JavadocVariable: Missing a