Can't wait to see it integrated, as I will add another PR based on the
previous one to emit a message and deprecate that new method.
Do I need to do something to have the PR merged?
On Sun, 29 Dec 2019, 17:38 Enrico Olivelli, wrote:
> Il dom 29 dic 2019, 16:02 Benjamin Marwell ha
> scritto:
Il dom 29 dic 2019, 16:02 Benjamin Marwell ha scritto:
> PR is updated.
>
> I found out that they might switch to semantic versioning as soon as they
> have cleaned the API: https://github.com/checkstyle/checkstyle/issues/3709
>
> That also means: the faster the current PR is integrated, the bett
PR is updated.
I found out that they might switch to semantic versioning as soon as they
have cleaned the API: https://github.com/checkstyle/checkstyle/issues/3709
That also means: the faster the current PR is integrated, the better - less
breaking changes for users.
On Mon, 23 Dec 2019, 18:00
On Mon 23 Dec 2019 at 15:44, Benjamin Marwell wrote:
> Furthermore,
>
> if we do not drop using that method, maven will throw an exception. Maven
> will, not checkstyle.
>
> I do not think that should be happening (from a user perspective).
>
> It's an easy fix for maven. As soon as the checkstyl
Le lun. 23 déc. 2019 à 17:51, Benjamin Marwell a
écrit :
> Sounds good to me.
>
> A new major is not needed for my PR, but needed for future versions of
> checkstyle. Depends on how fast they actually remove that method.
>
We can also just try catch the missing method, will not break us and work
Sounds good to me.
A new major is not needed for my PR, but needed for future versions of
checkstyle. Depends on how fast they actually remove that method.
3 is implemented via 2. 😉
On Mon, 23 Dec 2019, 16:50 Romain Manni-Bucau,
wrote:
> What about steps?
>
> 1. Ask them to grab the plugin (
What about steps?
1. Ask them to grab the plugin (with our support pby)
2. If 1 fails, semver and we align on that somehow in our versioning
(likely a new major?)
3. More tolerant fallback respecting user configured version, no user
breaking/enforced change (it hurts way too much even if nicer for
Furthermore,
if we do not drop using that method, maven will throw an exception. Maven
will, not checkstyle.
I do not think that should be happening (from a user perspective).
It's an easy fix for maven. As soon as the checkstyle Plugin required
checkstyle 8.24 or higher, it the plugin should go
+1 to move the plugin ... otherwise i dont see us breaking it since we
document - and cant help users doing it anyway - how to chnage the
checkstyle version, so we must support upgrades/downgrades as transparently
as possible, we are not in the mode "1 plugin version/ 1 checkstyle
version" so not s
Hi Mark,
The maven-checkstyle-plugin is rather pretty much hardcoded to a specific
checkstyle version. While you _could_ technically exchange the checkstyle
dependency it is not really intended.
Are you sure it is not really intended? It is actually _documented_:
https://maven.apache.org/pl
Robert>last time their argument was that they didn't have enough committers
to also maintain a maven plugin
TL;DR: I'm neither Maven nor Checkstyle committer, and I'm inclined that
the PR should be declined.
The case is as follows: there's a method in Checkstyle which is a no-op for
3 years or so
To me moving the plugin would help both projects.
IIRC the last time their argument was that they didn't have enough committers
to also maintain a maven plugin.
That's still a little bit weird if you compare that ratio (active committers
per LOCs) with the Maven Project.
Robert
On 23-12-2019 14:
Even if they don't accept it...
It would be helpful if they used semantic versioning. That way maintaining
that plugin would be much less of a hazzle.
As I created the PR, I'm going to ask them if they would develop the plugin
on their own, if you are okay with this.
On Mon, 23 Dec 2019, 13:57
I'd like to see it the other way around: move the plugin to the checkstyle team
(with or without help from someone of the maven team).
We've seen this more often in the past where products took over the plugins
from Apache Maven or Codehaus Mojo and it worked out well.
Now they can make the plu
Il lun 23 dic 2019, 12:58 Mark Struberg ha
scritto:
> But the main purpose is not to have multiple frameworks run with it.
> That's the main difference to surefire.
>
> The maven-checkstyle-plugin is rather pretty much hardcoded to a specific
> checkstyle version. While you _could_ technically ex
But the main purpose is not to have multiple frameworks run with it. That's the
main difference to surefire.
The maven-checkstyle-plugin is rather pretty much hardcoded to a specific
checkstyle version. While you _could_ technically exchange the checkstyle
dependency it is not really intended.
Point is it is the only way to not break end user since it gives us the
control of which version to select depending user config and java version.
Which we dont ask any change to user im fine either ways though.
Le lun. 23 déc. 2019 à 12:28, Benjamin Marwell a
écrit :
> I not think that would be
I not think that would be a benefit, because removing the class loader call
will also work with older versions of checkstyle.
Also, of the plugin is just a wrapper, why even bother to detect if the
checkstyle.xml and checkstyle dependency will work together?
Or am I missing something?
On Mon, 23
What about loading checkstyle from a dependency resolver and use a custom
classloader with an integration per version (a bit like surefire). It
enables to use any version and even detect an user override in plugin deps.
Le lun. 23 déc. 2019 à 09:27, Benjamin Marwell a
écrit :
> Hi Enrico,
>
> th
Hi Enrico,
that would mean a lot of incompatibilities which I wanted to avoid.
If the checkstyle jar is updated first (8.xx), maven users wouldn't be able
to use a current version for quite a while, because the Maven plugin would
throw NoSuchMethodExceptions. I wanted to avoid this.
On the other
Ben,
What about having a release of checkstyle with all of the requested changes
and then update maven plugin and then release it?
Checkstyle maven plugin is just a wrapper over checkstyle library.
The best way would be that you (or anyone from Checkstyle) create a PR when
you are ready with the n
21 matches
Mail list logo