If checkstyle 7+ requires Java 8 then this is a blocker for common-rng.
That still supports Java 1.6.
I did not intend to update commons-parent, only the project. The topic
of the parent was introduced just to state that there was no management
of checkstyle. The consensus appears to be that checkstyle versions are
maintained on a project basis and the version is possibly limited by
their Java dependency.
For now I will leave checkstyle config alone. Any project moving to Java
1.8 can upgrade.
The current workaround to get functionality within an IDE is to maintain
a local copy of the checkstyle.xml outside the source tree, updated for
checkstyle 8, and point the IDE plugin at that.
Thanks for the advice.
Alex
On 11/02/2019 21:15, sebb wrote:
On Mon, 11 Feb 2019 at 18:10, Pascal Schumacher
<pascalschumac...@gmx.net> wrote:
Am 11.02.2019 um 12:19 schrieb Alex Herbert:
I would like to upgrade the checkstyle version in commons-rng.
Currently the project uses maven-checkstyle-plugin 3.0.0 which
defaults to checkstyle 6.18.
This version is old [1] and not supported by modern IDEs. An update
(to version 8.x) would allow checkstyle to be run within the IDE and
avoid separate checks of the checkstyle report on the command line.
There is no management of the checkstyle version in commons-parent. I
would like to get a consensus on the versions used across commons and
any reason to not upgrade. There may be legacy reasons I am unaware of.
Checkstyle 7+ requires Java 8 and not that long ago (almost) all commons
projects required only Java 7 or less.
Imho commons-parent can use the most recent check-style version (8.17).
Of course this would force projects which use Java 7 or less to override
the checkstyle version when they update to the latest commons-parent
version.
Aren't there different profiles for different Java versions?
There was at least one plugin which needed different versions, so
maybe take the same approach here.
It's a bit more work to set up the pom, but it saves a lot of work
downstream fixing component poms and/or answering complaints that the
build fails ...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
