> I was referring instead to adding them to the build flow extensions > plugin[1] > > > > A plugin can define more than one extension - you do not need a 1:1 > mapping of plugin <-> extension. > > > > Some parts of the doc call it the 'concurrent extensions plugin', so it > doesn't look like it's for any new BF extensions.
Legacy. I first implemented the concurrent part. Then I added an extra bit that had nothing to do with concurrency (get latest stable build of X).. I then forgot about it and released an update of the plugin and was stuck... But that the extension is not tied 1:! to a plugin - you can have multiple extensions inside a plugin. you can either add a test to this block <https://github.com/jenkinsci/buildflow-extensions-plugin/blob/master/src/main/java/org/jenkinsci/plugins/buildflow/concurrent/extension/ConcurrentBuildFlowDSLExension.java#L48-L51> or just create a new @Extension class within the plugin It was always my intention that this would contain more than 2 keywords, but along came workflow with the 'James Nord' operator.. What I don't think benefits users is N plugins all contain a single buildflow extension. I will grant you that a kitchen sink approach isn't super useful either, but there should be some happy medium don't you think? -- 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/8247a6b4-e039-4046-8d39-70f916ffffef%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
