Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move to Java 8 & Jenkins 2.60 #389

Merged
merged 4 commits into from Jan 31, 2019

Conversation

Projects
None yet
2 participants
@framillien
Copy link

commented Jan 10, 2019

This change allow use of Java 8 enhancements and remove compatibility with Java 6 & 7.
Upgrade to Jenkins core 2.60 is needed to expose Java 8 requirement.

Some dependencies are updated to match new jenkins core and jenkins plugin POM parent changes, but many dependencies are still old: we could choose to upgrade them, too.

Dependencies update discussed in PR 383

Florian Ramillien added some commits Jan 2, 2019

Florian Ramillien
Move to java 8
Use last Jenkins plugin pom parent version
Do minimal dependencies update
Do some code changes for compatibility with newer dependencies versions
Florian Ramillien
Upgrade Jenkins Core to 2.14 and use AutoCloseable ACL's
+ some fixes for new Jenkins core compatibility
Florian Ramillien
Upgrade Jenkins core to 2.60
- Needed for explicit Java 8 requirement
- Fix NPE in doCheckDependencyJobsNames
- Fix ssh connection in tests (Replace DSA by RSA)
  Security error due to SHA1 use with too short keysize
@rsandell
Copy link
Member

left a comment

I've only skimmed through it bu thought I'd respond with the superficial stuff I found asap.

Interesting that you managed to do this without updating Mockito and PowerMock. Maybe that will hit once we start using lambdas and stuff?

<no-test-jar>false</no-test-jar>
<findbugs.failOnError>false</findbugs.failOnError>
<concurrency>1C</concurrency>
<powermock.version>1.6.2</powermock.version>
<checkstyle.version>2.13</checkstyle.version>
<mockito.version>1.10.19</mockito.version>
<workflow.version>1.14</workflow.version>
<workflow.version.test>1.14.1-beta-1</workflow.version.test>
<workflow.version>1.14.2</workflow.version>

This comment has been minimized.

Copy link
@rsandell

rsandell Jan 15, 2019

Member

I believe we need to bump this to some 2.x version of workflow and split up the versions to whatever latest that supports core 2.60. 1.14 of workflow is ancient.

This comment has been minimized.

Copy link
@framillien

framillien Jan 18, 2019

Author

All right, I check that.

This comment has been minimized.

Copy link
@framillien

framillien Jan 18, 2019

Author

I need some advice for this point. If I use workflow-step-api plugin versions targeted to java 8 (core 2.60), I get the last version of this plugin. I can't wonder if it's a problem or not. If we do that, gerrit-trigger-plugin users will be forced to use the last workflow-step-api version to update gerrit-trigger-plugin ?

May be not an issue, but I can't guess ...

Version of workflow-step-api needing java 8 / jenkins core 2.60 : 2.18 (january 2019)

This comment has been minimized.

Copy link
@framillien

framillien Jan 18, 2019

Author

workflow-aggregator needed for some tests introduce a lot of dependencies problems (maven enforcer). Do you think there is a good way to replace it for test, or we really need to deal with all depencies management ? Maybe we could get an example of dependencies management from other project using it ?

Or ... keep this versions of workflow plugins ? Since we do need new versions features, and their versions are drived Jenkins plugin management, it's an important issue ?

This comment has been minimized.

Copy link
@rsandell

rsandell Jan 31, 2019

Member

We don't have to go with the latest bleeding edge versions but something 2.x so that debugging etc gets easier to do.
Also as of workflow suite 2.0 there is no longer a mono repo of all the basics of workflow instead each plugin in the suite has it's own release cycle so we can't use the agregator any more.
See #390 for examples.

This comment has been minimized.

Copy link
@rsandell

rsandell Jan 31, 2019

Member

But we've also seen from usage statistics that those who update they update everything most of the time. And those who don't update won't care either way since they won't get this version that requires them to update everything :)

<groupId>org.jenkins-ci.plugins</groupId>
<artifactId>matrix-auth</artifactId>
<version>2.3</version>
<optional>true</optional>

This comment has been minimized.

Copy link
@rsandell

rsandell Jan 15, 2019

Member

Should this then be a test dependency instead?

This comment has been minimized.

Copy link
@framillien

framillien Jan 18, 2019

Author

Yes, I fix it.

@rsandell

This comment has been minimized.

Copy link
Member

commented Jan 31, 2019

I've fixed the test errors in #390 and think that's good enough to merge soon. It's this PR plus the workflow updates. And a bump to 2.121 instead of 2.60 which I guess is OK.
When that gets merged this PR should be auto merged as well since all the commits in this PR are in that as well.

@rsandell rsandell merged commit ebbc526 into jenkinsci:master Jan 31, 2019

1 check passed

continuous-integration/jenkins/pr-merge This commit looks good
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.