More checkstyle API changes

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

More checkstyle API changes

Benjamin Marwell
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
Reply | Threaded
Open this post in threaded view
|

Re: More checkstyle API changes

Benjamin Marwell
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, <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: More checkstyle API changes

Falko Modler
In reply to this post by Benjamin Marwell
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/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html

I've been using it this way for many years and I am sure many other
users have done the same.

Best regards,

Falko


Am 23.12.2019 um 12:57 schrieb Mark Struberg:

> 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.
>
> 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 <[hidden email]>:
>>
>> 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 <[hidden email]> 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, <[hidden email]>
>>> 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 <[hidden email]> 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, <[hidden email]>
>>> 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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: More checkstyle API changes

Romain Manni-Bucau
+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 sure we have the choice if they refuse the plugin.

Le lun. 23 déc. 2019 à 15:35, Falko Modler <[hidden email]> a écrit :

> 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/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html
>
> I've been using it this way for many years and I am sure many other
> users have done the same.
>
> Best regards,
>
> Falko
>
>
> Am 23.12.2019 um 12:57 schrieb Mark Struberg:
> > 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.
> >
> > 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 <
> [hidden email]>:
> >>
> >> 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 <[hidden email]> 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, <[hidden email]>
> >>> 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 <[hidden email]> 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, <[hidden email]>
> >>> 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 <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: More checkstyle API changes

stephenconnolly
In reply to this post by Falko Modler
On Mon 23 Dec 2019 at 15:44, Benjamin Marwell <[hidden email]> 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 checkstyle Plugin required
> checkstyle 8.24 or higher, it the plugin should go to 4.x (new major
> version). Simple as that.


Let’s not bump any plugin to 4.x at this time. Better if we can hold that
version number for plugins using Maven 4 as a baseline

>
>
> I am even willing to implement a Checkstyle version check to explain the
> incompatibilities of checkstyle 8.24 and above. It's not much work and will
> be helpful to users. Seeing some error ("TreeeWalker  does not allow the
> subelement LineLength") is not helpful by itself. It's easy to document and
> easy to detect.
>
> Also, why not ask the checkstyle team to adapt semantic versioning? Asking
> doesn't cost anything afaik.
>
>
> On Mon, 23 Dec 2019, 15:35 Falko Modler, <[hidden email]> wrote:
>
> > 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/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html
> >
> > I've been using it this way for many years and I am sure many other
> > users have done the same.
> >
> > Best regards,
> >
> > Falko
> >
> >
> > Am 23.12.2019 um 12:57 schrieb Mark Struberg:
> > > 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.
> > >
> > > 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 <
> > [hidden email]>:
> > >>
> > >> 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 <[hidden email]> 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, <
> [hidden email]>
> > >>> 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 <[hidden email]>
> 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, <[hidden email]>
> > >>> 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 <[hidden email]>
> 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
--
Sent from my phone