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 Robert Scholte, <rfscho...@apache.org> wrote: > 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 plugin part of the release and keep them in sync. > > Robert > > On 23-12-2019 13:21:34, Enrico Olivelli <eolive...@gmail.com> wrote: > 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 exchange the checkstyle > > dependency it is not really intended. > > > > This is exactly what I meant. > I think is it fine to release maven checkstyle plugin with a new version of > checkstyle. > Maybe in the future any of checkstyle team will become a Maven committer > and thisI will ease a lot this work > > > Enrico > > > > The 'compatibility' layer is rather only important for the checkstyle > > configuration. That part should really remain stable. If not, we have to > up > > to major version. > > > > LieGrue, > > strub > > > > > > > Am 23.12.2019 um 12:34 schrieb Romain Manni-Bucau > > >: > > > > > > 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 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 Dec 2019, 09:32 Romain Manni-Bucau, > > >> wrote: > > >> > > >>> 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, > > >>>> > > >>>> 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 hand, if the Maven plugin gets updated and released > > first, > > >>>> there is more time for users to migrate to a more recent maven > plugin. > > >>>> Hence my PR. > > >>>> > > >>>> I really do not see the benefit of updating the checkstyle jar first > > >> and > > >>>> this having a period of time where Maven users cannot use a recent > > >>> version > > >>>> of checkstyle at all. > > >>>> > > >>>> Maybe I did express the issue with checkstyle 8.24 in a wrong way. > > >> Users > > >>>> can already use it if they rewrite their checkstyle.xml. it's just > > that > > >>> the > > >>>> maven plugin should not update the default checkstyle version to not > > >>> break > > >>>> any default setups and force users to rewrite their checks. > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> On Mon, 23 Dec 2019, 08:45 Enrico Olivelli, > > >> wrote: > > >>>> > > >>>>> 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 new release. > > >>>>> > > >>>>> I will be happy to help you move forward with this change and cut a > > >>>> release > > >>>>> > > >>>>> Cheers > > >>>>> Enrico > > >>>>> > > >>>>> Il lun 23 dic 2019, 07:21 Benjamin Marwell ha > > >>>>> scritto: > > >>>>> > > >>>>>> Hi all, > > >>>>>> > > >>>>>> The checkstyle team is waiting for my PR: > > >>>>>> > > >>>>>> https://github.com/apache/maven-checkstyle-plugin/pull/18 > > >>>>>> > > >>>>>> The problem is, that they want to remove a method. If they do this > > >>> too > > >>>>>> early, maven users will not be able to update the checkstyle > > >> version > > >>>>>> anymore. > > >>>>>> > > >>>>>> Also, the maven Checkstyle plugin cannot ship a Checkstyle version > > >>>> beyond > > >>>>>> 8.23 because of breaking changes. There is also an issue for this. > > >>>>>> > > >>>>>> This really needs some attention by someone with more > > >> responsibility. > > >>>>>> > > >>>>>> Please keep in mind that there is already a jira issue about the > > >> 8.24 > > >>>>>> incompability. I commented that they should have made it a major > > >>>> version, > > >>>>>> and maybe the checkstyle plugin will have to jump to a new major > > >>>> release > > >>>>> at > > >>>>>> some point? > > >>>>>> > > >>>>>> Thanks for looking into this. > > >>>>>> > > >>>>>> Ben > > >>>>>> > > >>>>> > > >>>> > > >>> > > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
