[PROPOSAL] New Parent POM for Jenkins Plugins

[arodr...@cloudbees.com]

Hi all,

Please find below a proposal for a new parent POM for Jenkins Plugins.

Motivation

The main driver to propose a revision of the parent plugin POM is to decouple this artifact from the Jenkins Core:

• Simplifying the mechanism to build and test a plugin against different core versions.

• Decoupling build-related aspects, such as static analysis tools, JRE signatures, etc. from the baseline core versions, as they are totally independent concerns, reducing the need to include otherwise common configuration in each plugin POM just because we want to support and older baseline.

One use case that would greatly benefit from this change is for example, jenkins#1530, where it is necessary to propose API changes in core and matching plugin usages. The current plugins/pom.xml does not work if you mvn deploy a SNAPSHOT revision. Plugin Compatibility Testing can also benefit from this change.

Approach

As stated above the approach is based in making the plugin parent POM independent of the main Jenkins core project, and performing the following actions:

• Make the Jenkins Core version to use configurable via a property, so that a simple mvn -Djenkins.version=xxxx hpi:run is enough to compile and run a plugin with a different core version.

• Make the Jenkins Test Harness version to use also configurable (the default being the same Jenkins core version), for those cases that may need it, such as copyartifact#76.

• Reduce the number of Maven plugin pinned versions to those really used.

• Reduce the number of number of elements (versions, etc) overridable via properties to those that have a specific reason, setting the values to those intended to be used. There’s no reason to make everything overridable as the parent pom evolution is now independent of the baseline Jenkins Core versions.

Other aspects included:

• Default configuration for findbugs, including the possibility of automatically activating exclusions, and a property to define if findbug errors should break the build (default true).

• JRE signature verification configured to the Java level defined for the build (using a property as well).

• Regarding releases:

• Launching javadoc:javadoc in the prepare phase, in order to avoid the inconvenience “stricter” Java 8 javadoc breaking builds in the release phase.

• Skipping tests in the release phase, cutting release build times for plugins with a great number of tests.

• General cleanup.

Ok, show me the code

The current proposal is being pushed to https://github.com/andresrc/plugin-pom. It is not deployed to any repository yet, so in order to test it a local install is required. The artifactId is intentionally changed to avoid confusion. JIRA issue [JENKINS-32493] has been filed.

Some plugins have been used to verify the current proposal, including:

• Branch-API: https://github.com/jenkinsci/branch-api-plugin/pull/25

• Copyartifact: https://github.com/jenkinsci/copyartifact-plugin/pull/78

• Workflow: https://github.com/jenkinsci/workflow-plugin/pull/303

• Script Security: https://github.com/jenkinsci/script-security-plugin/pull/36

• Support Core: https://github.com/jenkinsci/support-core-plugin/pull/53

There is also an update on the Maven archetype at https://github.com/jenkinsci/maven-hpi-plugin/pull/27.

Next Steps

After collecting feedback from the community and if there’s certain consensus about going forward the next steps would be:

• Create a repository for the artifact in jenkinsci.

• Decide the final artifact maven coordinates.

• Perform a release.

• Update the documentation (wiki, etc.)

• Upgrade some plugins to use the new POM in order to drive adoption.

• Upgrade to PCT to support it.

Thanks!

[Robert Sandell]

+100

--
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/a0668ee9-908d-42c1-9b18-a98751869572%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Robert Sandell

Software Engineer

CloudBees Inc.

[Stephen Connolly]

+1000

We have been using the plugin parent that this is - in part - modelled on internally in CloudBees for quite a few years now. Jesse and I have long wanted to provide our plugin parent model to the community but we have lacked the time to push it forward. Thanks to Andres to take the time to convert our parent into one that can be consumed by the OSS community.

The only change I would - perhaps - make is to have the skipping of tests in the release:perform step controllable easily for an individual plugin... i.e. make it easy to turn on and off. Having had one or two occasions where re-running the tests in release:perform has saved my ass... I - personally - like to run them from release:perform and if I need to reduce the release time I would skip the tests during release:prepare ;-)

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS2EAbk6%2BjW9bCQ2ow1RtFKdEaz%3DU0-YP9sHWn3etunraw%40mail.gmail.com.

[Antonio Muñiz]

+1000 (-Djenkins.version, that single feature worth the change)

On Mon, Jan 18, 2016 at 10:35 AM, <arodr...@cloudbees.com> wrote:

--

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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/a0668ee9-908d-42c1-9b18-a98751869572%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Antonio Muñiz

Software Engineer
CloudBees, Inc.

[domi]

+100

--

[Jesse Glick]

On Mon, Jan 18, 2016 at 4:35 AM, <arodr...@cloudbees.com> wrote:
> Make the Jenkins Test Harness version to use also configurable (the default
> being the same Jenkins core version)

Since updated to use 2.0, now that it exists!

[Baptiste Mathus]

+1

Interested by jenkins.version sure, but also (even more?) by the fact it will be far easier to add things in that new parent that will be able to propagate far far quicker than upgrading to a more recent Jenkins base a like we have to do currently. (Example: upgrading the maven-hpi-plugin for one, and so on).

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/45406653-4295-4BD6-AC1B-B8624354F0A6%40fortysix.ch.

[Manuel Jesús Recena Soto]

Baptiste, I totally agree with you but in this case will be very
important to keep well-documented this parent-POM.

> https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6w7PF%3DY%3DvUE_%2B46-LOsPwP1Snt0n0nE0Ox3RX6fCHRcA%40mail.gmail.com.

>
> For more options, visit https://groups.google.com/d/optout.



--

Manuel Recena Soto
* manuelrecena.com [/blog]
* linkedin.com/in/recena

[arodr...@cloudbees.com]

Hi all,

Thanks for your comments.

After some adaptations for the jenkins test harness split and some of the comments received I've deployed a first snapshot a there is already a plugin CI build done using the experimental POM: https://github.com/jenkinsci/branch-api-plugin/pull/25

As stated in the first post, the next steps include:

• Decide the final artifact maven coordinates: following the criteria used in jenkins-test-harness, we could keep the same groupId / artifactId than before and bump version to 2.0.
• Create a repository in the jenkinsci GitHub org (by someone with permissions forking the existing one).
• Adapt the pom to the final SCM coordinates.
• Perform a release. 
  
• Update the documentation: I have already identified the wiki pages to modify.

Thanks,

Andrés

[Ullrich Hafner]

Since this is targeted for 2.0: are there also plans to avoid the dependency hell in future Jenkins releases within this pom or is this something that needs to be addressed somewhere else? Currently the Jenkins war exposes all dependencies (and transitive…) to the plug-ins. This leads to various library conflicts if a plug-in also needs a dependency e.g. in a different version.

 

-- 
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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/a21ab9f3-2371-4893-a89e-5fe4cfaa0daf%40googlegroups.com.

[Jesse Glick]

On Tue, Jan 19, 2016 at 6:45 AM, Ullrich Hafner
<ullrich...@gmail.com> wrote:
> Since this is targeted for 2.0

I do not see any reason to delay this change until 2.0. We can take
advantage of it immediately.

> are there also plans to avoid the dependency
> hell in future Jenkins releases within this pom or is this something that
> needs to be addressed somewhere else? Currently the Jenkins war exposes all
> dependencies (and transitive…) to the plug-ins.

Not a POM issue. Needs to be addressed in core’s `ClassLoader`s.

[Daniel Beck]

On 19.01.2016, at 15:28, Jesse Glick <jgl...@cloudbees.com> wrote:

>>
>> are there also plans to avoid the dependency
>> hell in future Jenkins releases within this pom or is this something that
>> needs to be addressed somewhere else? Currently the Jenkins war exposes all
>> dependencies (and transitive…) to the plug-ins.
>
> Not a POM issue. Needs to be addressed in core’s `ClassLoader`s.

FWIW we have a 2.0 labeled issue for this, but I'm not sure this is being planned to be implemented right now:
https://issues.jenkins-ci.org/browse/JENKINS-30685

[Jesse Glick]

On Tue, Jan 19, 2016 at 6:27 AM, <arodr...@cloudbees.com> wrote:
> Decide the final artifact maven coordinates: following the criteria used in
> jenkins-test-harness, we could keep the same groupId / artifactId than
> before and bump version to 2.0.

Yes I think making it be `org.jenkins-ci.plugins:plugin:pom:2.0` would
be appropriate. If nothing else, this advertises it as an upgrade for
people who use standard Maven tools or IDEs to look for new versions
of artifacts (in this case parent POM). Of course you need to make
certain changes to your plugin’s POM to use it (in most cases you
would want to define `jenkins.version` at a minimum), but that seems
OK—the bump in major version should be sufficient indication that
something noteworthy has changed.

> Create a repository in the jenkinsci GitHub org (by someone with permissions
> forking the existing one).

I can do this if there are no objections. The main question is the
repository name. `plugin-pom`?

> Perform a release.

And I suggest that `jenkinsci/jenkins/plugins/pom.xml` be deleted.

[Jesse Glick]

On Mon, Jan 18, 2016 at 4:35 AM, <arodr...@cloudbees.com> wrote:

> The current proposal is being pushed to
> https://github.com/andresrc/plugin-pom.

Since there is no PR for the POM itself, I am putting comments here.

`<issueManagement>` does not seem like it belongs. The POM need not be
used by plugins hosted under the Jenkins organization.

AFAIK the test dependency on `jenkins-war` should be on
`<classifier>war-for-test</classifier>`, not `<type>war</type>`.

I would suggest `<preparationGoals>javadoc:javadoc clean
install</preparationGoals>` rather than `<preparationGoals>clean
install javadoc:javadoc</preparationGoals>` since Javadoc generation
is likely a lot faster than running tests, and more likely to be
failing without anyone knowing about it before.

Consider https://github.com/jenkinsci/workflow-plugin/blob/master/pom.xml#L201-L211
which I have found invaluable. Could be added later of course.

[Jesse Glick]

On Tue, Jan 19, 2016 at 2:49 PM, Jesse Glick <jgl...@cloudbees.com> wrote:
> Since there is no PR for the POM itself, I am putting comments here.

…and added further comments to the PRs for various plugins. BTW now
that you have deployed a snapshot you should close & reopen those PRs
so we can see if the result actually builds.

[Stephen Connolly]

On Tuesday 19 January 2016, Jesse Glick <jgl...@cloudbees.com> wrote:

On Mon, Jan 18, 2016 at 4:35 AM,  <arodr...@cloudbees.com> wrote:
> The current proposal is being pushed to
> https://github.com/andresrc/plugin-pom.

Since there is no PR for the POM itself, I am putting comments here.

`<issueManagement>` does not seem like it belongs. The POM need not be
used by plugins hosted under the Jenkins organization.

AFAIK the test dependency on `jenkins-war` should be on
`<classifier>war-for-test</classifier>`, not `<type>war</type>`.

I would suggest `<preparationGoals>javadoc:javadoc clean
install</preparationGoals>` rather than `<preparationGoals>clean
install javadoc:javadoc</preparationGoals>` since Javadoc generation
is likely a lot faster than running tests, and more likely to be
failing without anyone knowing about it before.

-1 as that may give a false fail on a clean checkout where the javadoc plugin references generated classes etc and Java 8 is being strict.

 

Consider https://github.com/jenkinsci/workflow-plugin/blob/master/pom.xml#L201-L211
which I have found invaluable. Could be added later of course.

--
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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0ZHQrbgT1QP5G3DxgifLTO4M1g3ZkMv-H7aVK3_1g_XQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
Sent from my phone

[Andres Rodriguez]

On Tue, Jan 19, 2016 at 8:19 PM, Jesse Glick <jgl...@cloudbees.com> wrote:

On Tue, Jan 19, 2016 at 6:27 AM,  <arodr...@cloudbees.com> wrote:
> Decide the final artifact maven coordinates: following the criteria used in
> jenkins-test-harness, we could keep the same groupId / artifactId than
> before and bump version to 2.0.

Yes I think making it be `org.jenkins-ci.plugins:plugin:pom:2.0` would
be appropriate. If nothing else, this advertises it as an upgrade for
people who use standard Maven tools or IDEs to look for new versions
of artifacts (in this case parent POM). Of course you need to make
certain changes to your plugin’s POM to use it (in most cases you
would want to define `jenkins.version` at a minimum), but that seems
OK—the bump in major version should be sufficient indication that
something noteworthy has changed.

That was my thought as well. It has already been updated to to those coordinates.

 

> Create a repository in the jenkinsci GitHub org (by someone with permissions
> forking the existing one).

I can do this if there are no objections. The main question is the
repository name. `plugin-pom`?

That was my thought as well. I checked is was available before creating the initial repo.

 

> Perform a release.

And I suggest that `jenkinsci/jenkins/plugins/pom.xml` be deleted.

Sure, I'll prepare a PR.

Thanks

 

--
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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0A6jrobt2phksSqC9cE_qh%3D56wEnhOmurhFerj5DgRmA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Regards,

Andres Rodriguez

www.cloudbees.com

[Andres Rodriguez]

On Tue, Jan 19, 2016 at 8:49 PM, Jesse Glick <jgl...@cloudbees.com> wrote:

On Mon, Jan 18, 2016 at 4:35 AM,  <arodr...@cloudbees.com> wrote:
> The current proposal is being pushed to
> https://github.com/andresrc/plugin-pom.

Since there is no PR for the POM itself, I am putting comments here.

`<issueManagement>` does not seem like it belongs. The POM need not be
used by plugins hosted under the Jenkins organization.

Done

 

AFAIK the test dependency on `jenkins-war` should be on
`<classifier>war-for-test</classifier>`, not `<type>war</type>`.

Done

 

I would suggest `<preparationGoals>javadoc:javadoc clean
install</preparationGoals>` rather than `<preparationGoals>clean
install javadoc:javadoc</preparationGoals>` since Javadoc generation
is likely a lot faster than running tests, and more likely to be
failing without anyone knowing about it before.

Consider https://github.com/jenkinsci/workflow-plugin/blob/master/pom.xml#L201-L211
which I have found invaluable. Could be added later of course.

I've added a mix between the existing approach and workflow's, in order to keep the exclusionFilter profile optional as well.

I've also moved running javadoc when tests are active to a profile and removed it from the release profile.

 

--
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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0ZHQrbgT1QP5G3DxgifLTO4M1g3ZkMv-H7aVK3_1g_XQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Jesse Glick]

On Wed, Jan 20, 2016 at 4:22 AM, Stephen Connolly
<stephen.al...@gmail.com> wrote:
>> I would suggest `<preparationGoals>javadoc:javadoc clean
>> install</preparationGoals>`
>

> -1 as that may give a false fail on a clean checkout where the javadoc
> plugin references generated classes

Possibly. What I do in `workflow-plugin`, which has served me well, is
to just include `javadoc:javadoc` in a profile activated when not
`skipTests`. That ensures that all “full builds” including CI verify
the absence of Javadoc errors, so you do not get a nasty surprise on
release day. Routine developer builds—where you are just trying to get
artifacts created so you can `hpi:run` etc.—do not incur the expense.

[Andres Rodriguez]

That has been included, but independently of findbugs: https://github.com/andresrc/plugin-pom/blob/03f2c716f68f9142d3b8fbb14fd9b8af3d154b0a/pom.xml#L804-L827

 

--
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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr05ksqCt7UJmKd4FWnZUMtNAXASO6ESShWt-3hmqAYXUg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Regards,

Andres Rodriguez

www.cloudbees.com

[Andres Rodriguez]

Hi,

A first version with coordinates `org.jenkins-ci.plugins:plugin:pom:2.0` has been released.

The source is now at its new location https://github.com/jenkinsci/plugin-pom.

Regards,

Andrés

[Robert Sandell]

Thanks!

Is there any known minimum version of core this can work with?
E.g. can I update my plugin to this with jenkins.version=1.404 ?

Or maybe is there some recommended minimum core to start using this with?

I was thinking of the usage of npm and node settings might assume things?

/B

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAM9%3DZ%2B7OJrWbhsLFkTavDqDTeZhkkM0tyYfy8hC1jKyxL1FZmA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

[Robert Sandell]

Maybe it's the test harness that is setting the lower limit of 1.580.1

.B

[Andres Rodriguez]

Hi,

We've done tests with versions back to 1.509.4. Adjusting `jekins.version`, `jenkins-test-harness.version` and java.level to the appropriate settings should be no problem for previous versions.

Regarding node stuff, you have `node.version`and `npm.version`properties, but other customization may require overriding some config in the profiles. 

Thanks!

On Thu, Jan 21, 2016 at 11:07 AM, Robert Sandell <rsan...@cloudbees.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS20iY1vg0nkRW8P5dBDgctCdnGP%3DC8O%2B1mYZg3u4bBJVw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Andres Rodriguez]

You can set JTH to the version you need: `jenkins-test-harness.version`

Thanks!

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS2MTGRfjBDdvBjae9hUWqVwPwGApY7cyoirzpCOw7OXNQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Stephen Connolly]

Well we started our internal parent pom at 1.400 so as long as *you* consult the older versions of that you should be able to infer the correct versions of hpi plugin and stapler plugin to build against such a really old core...

If *you* do that, could you record those details for the community - as they don't have access to our repositories

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS20iY1vg0nkRW8P5dBDgctCdnGP%3DC8O%2B1mYZg3u4bBJVw%40mail.gmail.com.

[Jesse Glick]

On Fri, Jan 22, 2016 at 4:28 AM, Stephen Connolly
<stephen.al...@gmail.com> wrote:
> Well we started our internal parent pom at 1.400 so as long as *you* consult
> the older versions of that you should be able to infer the correct versions
> of hpi plugin and stapler plugin to build against such a really old core...

FWIW I have in my `~/.m2/settings.xml` profiles such as

<profile>
<id>jenkins-565</id>
<properties>
<jenkins.version>1.565.3</jenkins.version>
<hpi-plugin.version>1.106</hpi-plugin.version>
<java.level>6</java.level>
</properties>
</profile>

It might be worth writing and testing a series of such profiles for
all reasonably recent LTS lines and adding them to `plugin-pom` for
everyone to benefit from. Then without any work, you could check your
plugin’s behavior against a different line very easily:

mvn -Pjenkins-642 clean verify

[Jesse Glick]

Update: we are up to 2.2, and 1.645 will have been the last release of
the old POM.

[Baptiste Mathus]

Hi,

Trying to build on an old version (1.447.2), I get the following error:

Found Banned Dependency: org.sonatype.sisu:sisu-guice:jar:3.1.0

Before/while excluding the dependency I'd like to understand, could someone provide some context about that? 

IIUC, this may be because we already use guice, and sisu-guice is a patched one, so it would indeed conflict. 

The question is: does it mean a whole bunch of plugins potentially would still be embedding currently sisu-guice?

I think that it would be good to document why those dependencies are banned as a comment in https://github.com/jenkinsci/plugin-pom/blob/master/pom.xml#L510L514 

Thanks for the feedback

2016-01-22 19:58 GMT+01:00 Jesse Glick <jgl...@cloudbees.com>:

Update: we are up to 2.2, and 1.645 will have been the last release of
the old POM.

--
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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1ZCqu8FAz7M254cFPWb4KPw9uXZx7aPjtdkOT2fe_EUA%40mail.gmail.com.

[Andres Rodriguez]

Hi Baptiste,

The exclusions where introduced in this PR: https://github.com/jenkinsci/jenkins/pull/1816

I'll try to get more context to include in the POM comments.

Thanks!

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6oZkExqbd%3DxzmTKVL-W%3DrX5LW_-5tHCHoqEceoQBOHug%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.