Skip to content

Conversation

@jglick
Copy link
Member

@jglick jglick commented Apr 26, 2018

As suggested by @oleg-nenashev in #96, enumerating plugins known to be using APIs which would clash with remote artifact storage. CC @carlossg

Copy link
Member

@oleg-nenashev oleg-nenashev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for doing that! Looks good. For obsolete API usages it may make sense to create a follow-up ticket to the core


=== Master-based file streaming

Some plugins using ``VirtualFile``s corresponding to build artifacts are still calling `open`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wow, didn't know about this syntax (double-single-quote)

As seen in
link:https://ci.jenkins.io/job/Infra/job/deprecated-usage-in-plugins/job/master/lastSuccessfulBuild/artifact/output/usage-by-api.html#hudson_model_Run_getArtifactsDir__Ljava_io_File_[this report],
there are a number of plugins on the usual update center still calling `Run.getArtifactsDir()` and/or `Run.Artifact.getFile()`,
despite the fact that these methods were deprecated in Jenkins 1.531 in 2013 as part of
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it makes sense to modify the API methods and to print WARNINGs if these APIs are used with custom ArtifactManager configurations. Then it can be somehow routed to telemetry in JEP-304

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, was already suggested in this JEP, but does not do much good until JEP-304 is live I suppose.

[cols="5,>",options="header",width="50%"]
|============================
|Plugin|Installations
|link:https://plugins.jenkins.io/maven-plugin[Maven Integration]|124783
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, should we rename it to die-hard-plugin? :D

These include:

[cols="5,>",options="header",width="50%"]
|============================
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to create RFE tickets and reference them from JEP? maybe it's rather preferable to it in a Wiki page so that we could do it dynamically (like https://wiki.jenkins.io/display/JENKINS/Plugins+affected+by+fix+for+JEP-200 or https://wiki.jenkins.io/display/JENKINS/Plugins+affected+by+fix+for+SECURITY-170)

Then the warning message for old API could redirect people to that page

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not consider it worth bothering given the limited impact and the low installation counts. Would be possible if adding core logging, of course.

At any rate, that does not seem to have much bearing on the text of the JEP.

@bitwiseman
Copy link
Contributor

@oleg-nenashev You approved but then didn't merge. Should this be merged on not?

@jglick jglick mentioned this pull request Apr 26, 2018
@oleg-nenashev
Copy link
Member

I didn't merge it because there was no JEP Sponsor's approval at that point.
Merging it now

@oleg-nenashev oleg-nenashev merged commit b907c8b into jenkinsci:master Apr 27, 2018
@jglick jglick deleted the JEP-202-appendix branch April 28, 2018 01:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants