cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <>
Subject Re: [DISCUSS] Java 7, tomcat 7 and further upgrades
Date Wed, 26 Jun 2013 23:16:11 GMT
On Thu, Jun 27, 2013 at 4:06 AM, Hugo Trippaers <> wrote:

> Hey everyone,
> Back in February 2013 Oracle announced the end of public support for java
> 1.6 already. Today we are still using java 1.6 as our supported platform.
> I've been looking at the next generation of linux distributions (well
> mainly at Fedora 18, which will probably become RHEL 7) and those platforms
> ship with java 1.7 by default.
> Next to that several core components are also upgraded with affect our
> installation. RHEL 7 will most likely use tomcat 7 as the default tomcat
> platform for example.
> If we want to start shipping for those platform we will have to start
> testing with these versions of the software as well. I'm already working on
> some things that need to be done, like replacing the existing init scripts
> with systemd versions and adapting the spec file for the new OS, but there
> is more to it than that.
> I'm wondering what we need to do on the source side of things. My proposal
> would be to at least configure maven to set the source version to 1.7.

+1 Let's do it!

> This requires developers to use the java 7 versions of the jdk. We can
> leave the target to 1.6 for the time being to ensure that the packages
> could still run on a 1.6 jdk.
> However at a certain point we should start to advice people to run
> CloudStack on java 1.7 as there are no more public security updates to java
> 1.6.
> So summarized proposal, make 4.2 the last version to support 1.6 and
> switch maven source version to 1.7 after we cut the release branch for 4.2.
> The new reference platform for the next release would be jdk 1.7 and
> tomcat7 (meaning packaging will be tested on those platforms).


> So what do you all think of this? If we are ok to do this i would like to
> start with this right after the release branch cut. This constitutes a
> major architecture change so i would want this to be in as early as
> possible in the release cycle.

We should do it, we don't have much choice I guess if 1.6 will go away, it
makes sense to adapt and build on the latest.

And as a side note, are there any other version updates we would like to
> see in that release. We depend on several ancient libraries if i'm looking
> through the pom files. Maybe we should consider upgrading a few
> dependencies to more recent versions?

Few of the dependencies have issues, so upgrading few of them can actually
break stuff, for example in cloudstack-awsapi. But, yes we should upgrade
the rest of the dependencies, have the latest/stable ones.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message