I mean not shared code, but exactly code related to plugin lifecycle in 'Plugin' class as it obvious place. With annotations in different parts of code you can't handle sequence of actions during start/stop. Spreading many start/stop/post-init hooks with annotations in different classes makes not obvious lifecycle, that's why using such Plugin class looks ok for me. If people don't know right extension points, then javadoc should only reference imho.
On Wednesday, November 18, 2015 at 11:31:41 PM UTC+3, Jesse Glick wrote: > > On Wed, Nov 18, 2015 at 1:21 PM, Kanstantsin Shautsou > <[email protected] <javascript:>> wrote: > > I thought it is right entry Point if somebody wants to use some plugin > specific actions as it obvious entry point for plugin > > Maybe I am not understanding what you wrote, but why do you need to > extend `Plugin` at all if you just want a class where you can put some > general-purpose code used throughout the plugin? > > > I also thought that start/postInitialize is used to get earlier actions > for magic actions (i.e. alias XStream entries). > > You can do such things in `@Initializer`. (Sometimes people use > `static` blocks in `Descriptor`s, in the particular case of XStream > aliases pertaining to the corresponding `Describable`, though that > idiom might break if we implement JENKINS-22050.) > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/e8596a6c-10b9-4cc9-a3f3-13c48858c549%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
