Anyone working on Doxia these days? If so, your review of
https://github.com/apache/maven-doxia-tools/pull/3 would be
appreciated. This PR effectively disables a flaky autogenerated test.
This was the best I could come up with on short notice to unblock some
other bugs in Doxia. However if anyone
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
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
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
+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
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_:
This morning I finished reviewing the last of these issues. Only four
remain untouched, all of which were previously autoclosed and
reopened, so we shouldn't autoclose them again.
I didn't keep track of exact numbers of how many I closed,
reprioritized, duped, marked abandoned etc. There were a
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
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
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,
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
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
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
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,
>
>
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
18 matches
Mail list logo
