Pluging development - version confusion

[Scott Dunbar]

Hello,
I'm trying to develop a pretty simple plugin that will work with a proprietary internal server.  Jenkins versioning is a bit overwhelming and I've gotten now where I must have an incompatible version situation.

My Jenkins server is version 2.89.2 which is the latest available from the debian-stable repository - I'm not even sure that matters.

For the parent part of the pom.xml I have:

    <parent>
        <groupId>org.jenkins-ci.plugins</groupId>
        <artifactId>plugin</artifactId>
        <version>2.37</version>
        <relativePath />
    </parent>

as taken from https://wiki.jenkins.io/display/JENKINS/Plugin+tutorial (though with an updated version).  Later, I have:

    <properties>
        <jenkins.version>2.89.2</jenkins.version>
        <version>2.37</version>
        <java.level>8</java.level>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

and it's here I get in trouble.  I have some dependencies on some AWS libraries and Apache HTTP Client but when I try to run "mvn hpi:run" (or package or install) I ultimately get an error:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile (default-compile) on project formPoller: Compilation failure
[ERROR] javax.annotation.processing.FilerException: Attempt to reopen a file for path C:\Users\sdunbar\work\company\jenkins-form-poller\target\classes\com\company\jenkins\form\NewFormPoller.stapler

I have a config.jelly in the resources tree of that package along with a .properties and a few help HTML files.  In the java tree I have a single .java file that extends Builder and implements SimpleBuildStep.

Ultimately I guess my question is how can I use reasonably recent code that will work with my Jenkins server.  I appreciate that there is frequent development but I'm lost as to what version of the "org.jenkins-ci.plugins.plugin" artifact to use that works with my Jenkins - the versions do not appear to be the same across the server and the plugin.

Sorry for the long question - thanks for any help.

[Jesse Glick]

On Mon, Jan 22, 2018 at 4:57 PM, Scott Dunbar <sc...@xigole.com> wrote:
> when I try to run "mvn hpi:run" (or
> package or install) I ultimately get an error:
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile
> (default-compile) on project formPoller: Compilation failure
> [ERROR] javax.annotation.processing.FilerException: Attempt to reopen a file
> for path
> C:\Users\sdunbar\work\company\jenkins-form-poller\target\classes\com\company\jenkins\form\NewFormPoller.stapler

Try:

mvn clean

> I'm lost as to what version of the
> "org.jenkins-ci.plugins.plugin" artifact to use that works with my Jenkins

The one you have is fine.

> the versions do not appear to be the same across the server and the plugin.

Correct, they are versioned independently.

[Scott Dunbar]

On Monday, January 22, 2018 at 3:19:31 PM UTC-7, Scott Dunbar wrote:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile (default-compile) on project formPoller: Compilation failure
[ERROR] javax.annotation.processing.FilerException: Attempt to reopen a file for path C:\Users\sdunbar\work\company\jenkins-form-poller\target\classes\com\company\jenkins\form\NewFormPoller.stapler

For intrepid future web surfers running across the same issue - the issue was that I had two @DataBoundConstructors in my Builder.  I was attempting to get a nested JSON structure parsing from an optionBlock inside of the Jelly file and had added two of the constructors.  Obviously that's not correct.

[Jesse Glick]

On Tue, Jan 23, 2018 at 3:40 PM, Scott Dunbar <sc...@xigole.com> wrote:
> I was attempting
> to get a nested JSON structure parsing from an optionBlock inside of the
> Jelly file and had added two of the constructors. Obviously that's not
> correct.

No, it is not. To do things the Jenkins Way™ you need something like
`f:optionalProperty` and a distinct `Describable` type (with its own
`config.jelly`) for the nested structure, at which point you simply
declare a property of that nested type and there is no need to fool
around with low-level JSON stuff or legacy controls. See
`ui-samples-plugin` for examples of this kind of thing.