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

[4.9+] WIP: Support Java 8, Maven 3.3, Upgraded dependencies #1370

Closed
wants to merge 4 commits into from

Conversation

rohityadavcloud
Copy link
Member

Was learning about JDK8, lambdas, streams etc today. Thought it would be a good idea to get ACS codebase to latest mvn and jdk8. This is a WIP branch pushed on ACS remote so feel free to push changes if you're a committer or send PR.

Major changes:

  • Moved to latest JDK8
  • Moved to latest Maven 3.3.9 (-T threaded compilations appears faster)
  • Upgraded several dependencies to latest minor versions (or major in few cases)

What fails/unsupported or TODOs:

  • Unit tests in cloud-server and few other places
  • F5 plugin fails, tried to resolve the issue but I was unable to grok it
  • Major spring framework version (that would be a lot of work on its own)
  • Major servlet version changes
  • Fix packaging, init.d/system.d JAVA_HOME paths
  • Check ACS agents with JDK/JRE8 (kvm, cpvm, ssvm)
  • Check and configure GC related changes wrt JRE7/JRE8 (in any configs, say tomcat configs)
  • Check against compatibility guide: http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html

What works:

  • Compiling in -Dnoredist with -DskipTests to test if ACS codebase (minus unit tests) worked (non-issue once we fix the failing unit tests)
  • Deploy db worked
  • Running the management server locally with Java8

Skipped: (but upgraded to latest minor release)
- Major spring framework version
- Servlet version
- Embedded jetty version
- Mockito version (beta)
- Mysql lib minor version upgrade (breaks mysql-ha plugin)

Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
Fixes a checkstyle issue for enums, breaks with newer checkstyle versions

Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
Comment out F5 plugin which breaks for an unresolved issue:
cloudstack/plugins/network-elements/f5/src/com/cloud/network/resource/F5BigIpResource.java
--> cannot access Stub

We should fix it once we can get an updated iControl.jar or get this issue fixed

Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
@rohityadavcloud rohityadavcloud changed the title Support jdk8 mvnupgrades [4.9+] WIP: Support jdk8 mvnupgrades Jan 27, 2016
@rohityadavcloud rohityadavcloud changed the title [4.9+] WIP: Support jdk8 mvnupgrades [4.9+] WIP: Support Java 8, Maven 3.3, Upgraded dependencies Jan 27, 2016
@rohityadavcloud
Copy link
Member Author

@wido
Copy link
Contributor

wido commented Jan 27, 2016

I agree with switching to Java 8, but shouldn't this be a small PR first where we ONLY switch to Java 8?

Other PRs can follow up quickly.

@rohityadavcloud
Copy link
Member Author

@wido I was getting some compilation issue specifically to F5, to which someone previously on ML had advised an issue related to dependency version so I've included upgrading dependency version (to stable/latest minor revision but no major version changes causing compatibility issues). Unfortunately, I did that but F5 was still not happy while getting compiled.

@jburwell
Copy link
Contributor

To ease transition, it seems like the first step should be to support running ACS built to 1.7 on a 1.8 runtime. This approach would allow customers unprepared to transition to continue using Java7. We would then notify users that Java7 support has been deprecated and will be removed in two releases (two months).

@rohityadavcloud
Copy link
Member Author

Alright, let's keep this PR hanging then. We should then open another PR which fixes the packaging first to switch from JRE7 to JRE8 along with any JAVA_OPT or tomcat config changes

@jburwell
Copy link
Contributor

@bhaisaab if we make the packaging require Java 1.8, then users will be automatically upgraded -- defeating the purpose of the deprecation. It seems like an appropriate first step is to audit all dependencies for Java8 support, and upgrade all affected dependencies. For example, we need to upgrade to Spring 4 because Spring 3 does not support Java 8. In my opinion, we should perform the dependency upgrades as part of 4.9.

@@ -38,7 +38,7 @@
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-bundle-jaxrs</artifactId>
<version>2.7.13</version>
<version>2.7.18</version>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can the version become a var in the root pom?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure.

Wondering if we can remove many of the engine/{projects}; not sure where it is used or who uses that. Looks like a WIP attempt to creating a RESTful api server.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants