On Friday, March 13, 2015 at 10:41:43 AM UTC-4, Nicolas Reibel wrote:
>
> I am working on a quite complex post-action build, where the user can 
> select which info to display through a hetero-list.
>

First of all, this might better be sent to jenkinsci-dev.
 

> For this purpose, I overwrote the function newInstance from the plugin 
> descriptor to call function DescribableList.rebuildHetero(...)
>

This is a red flag. You should not need to override newInstance, even for 
complex hetero lists. You just need a getter + @DataBoundSetter taking a 
collection of your Describable subclass. (You may use a 
@DataBoundConstructor parameter instead of a setter if the attribute should 
be considered mandatory.)

https://github.com/jenkinsci/ui-samples-plugin/blob/2ab631671f90abf496e319b8334ce32c414d9dc7/src/main/java/jenkins/plugins/ui_samples/HeteroList.java#L89-97

Now I am studying the possible integration with the Workflow plugin, and so 
> far, the only way I know to set up this describable list is to instantiate 
> all items by hand, and create a DataBoundSetter
>

If you use normal databinding, the Snippet Generator will offer a syntax 
that does not use the `new` keyword or otherwise refer directly to Java 
types (which would be undesirable anyway since such scripts could not run 
in the sandbox for a secured Jenkins installation). It should be offering 
something like

step($class: 'YourPublisher', input: 'out.xml', items: [[$class: 
'ItemType1', param: 'SomeParameter'], [$class: 'ItemType2', param: 
'SomeParameter']])

Not an ideal syntax but at least the UI can assist you in writing it (and a 
future version of Workflow may offer a streamlined syntax automatically).

in FreeStyleProjects, a new plugin instance is generated for the project 
> each time the configuration is changed, and builds can easily find a 
> reference to it. Here, a new plugin is configured for each run, is that 
> right?
>

If by “new plugin instance” you mean “new Publisher instance”, then yes 
that is correct.

that means any change I do to a job (change the items to be displayed) 
> won't affect other builds
>

You mean historical builds? Sure, they will use whatever configuration the 
script specified when the build was run. If you think you want it 
otherwise, you are designing something the wrong way.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" 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-users/24bc703f-cf0a-49bf-85a4-3e9cac3a348d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to