-
New Feature
-
Resolution: Unresolved
-
Major
-
None
the jclouds plugin (ec2, openstack, etc compatible slave launcher) is currently rev-locked to <guava 12, as the project reverted back to guava 11 to ensure JDK5 compatibility. This means the plugin cannot get latest jclouds updates, which employ guava 12 features.
We don't want to be limited to JDK5 libraries forever. How can plugins use modern libraries while this restriction is in place? Is there another build we can make for JDK6+ only?
- is related to
-
JENKINS-13667 JDK5 Compatibility is broken since migration from Guava 11 to Guava 12
-
- Resolved
-
[JENKINS-14127] Support Libraries with dependencies on JDK 6 libraries
Monty Taylor
added a comment - I don't know what the distribution mechanics would be for a split build, but since Jenkins is a standalone service, I find it hard to imagine why supporting JDK5 would be important. (I would understand it more if it were a library that enterprises who are stuck in the stone age were wanting to consume inside of their antiquated applications)
Monty Taylor
added a comment - I don't know what the distribution mechanics would be for a split build, but since Jenkins is a standalone service, I find it hard to imagine why supporting JDK5 would be important. (I would understand it more if it were a library that enterprises who are stuck in the stone age were wanting to consume inside of their antiquated applications) Are you sure we're actually blocked here? We've got the ability to exclude things from the main Jenkins classloader in the plugin's classloader, which is how we were dealing with the guava thing. Is that not working now?
Interesting 
snippets from the Jenkins POM [1]: lines 558-9 set the source and target Java versions to 1.5, but then in lines 578-81 we find
<!-- There is a bug in JDK 1.5's compiler therefore need to compile with 1.6 --> <requireJavaVersion> <version>1.6.0-18</version> </requireJavaVersion>
So if Jenkins seemingly requires a 1.6 compiler to be built, it shouldn't be a problem to build it with source and target versions of 1.6.
I understand Monty's point about compatibility but from this it would seem that a split build should not require any code changes...
[1] https://github.com/jenkinsci/jenkins/blob/master/pom.xml
Andrew Phillips
added a comment - - edited Interesting snippets from the Jenkins POM [1] : lines 558-9 set the source and target Java versions to 1.5, but then in lines 578-81 we find
<!-- There is a bug in JDK 1.5's compiler therefore need to compile with 1.6 -->
<requireJavaVersion>
<version>1.6.0-18</version>
</requireJavaVersion>
So if Jenkins seemingly requires a 1.6 compiler to be built , it shouldn't be a problem to build it with source and target versions of 1.6.
I understand Monty's point about compatibility but from this it would seem that a split build should not require any code changes...
[1] https://github.com/jenkinsci/jenkins/blob/master/pom.xml Andrew Phillips
added a comment - Just to follow up on compiling against 1.6: after cloning the Jenkins repo (as at commit e942555f) I was able to change the source and target versions to 1.6, the Guava version to 12.0 and to run 'mvn clean package'.
The resulting WAR seems to start fine.
Andrew Phillips
added a comment - Just to follow up on compiling against 1.6: after cloning the Jenkins repo (as at commit e942555f) I was able to change the source and target versions to 1.6, the Guava version to 12.0 and to run 'mvn clean package'.
The resulting WAR seems to start fine. 
issue where guava 12 was reverted