1
votes

~We have some projects still running in AEM 6.1 SP2 (the move to newest version of AEM is in progress) and new projects in AEM 6.5. AEM 6.1 runs in java 8 and AEM 6.5 runs in java 11. For us developers this switching between jdk versions is difficult in our local environment, quite often we get our AEM instances corrupted or maven project imports are no longer working properly in IDE. Anyone else had this situation? What are the best practices for such a situation?

3
We recently did the upgrade from aem 6.3 to 6.5 and in the meantime also switched to java11. We had no real problems with the switching because we use virtualbox to run our aem instances, so we could run multiple aem instances at the same time, all with different java versions.YFrickx
thanks @YFrickx we thought about VM or a docker to be able to spin a new instance faster than it would normally take.Diana R

3 Answers

2
votes

My recommendation would be to set up vagrant box instances to your specs (AEM version + Java) and use automated deployments. This way, you can bring up a preconfigured instances in minutes by executing a single vagrant up command, run your automated deployment, and test your projects. If your instance gets corrupted, run a vagrant destroy command, bring up a new instance again with 0 configurations needed for the next deployment. You willincrease your productivity manifolds with this approach.

I have been using this approach for years and it has saved hours of devops work during critical project timelines

1
votes

If you are using MAC [OSX], you can try Jenv. It can help you to have a unique Java Environment to a specific directory. We did find it very useful.

https://github.com/jenv/jenv

Thanks!

0
votes

If you are running your AEM instances via shell scripts E.g. ./crx-quickstart/bin/start you can always specify the JAVA_HOME variable to be used in this particular file.

E.g.

export JAVA_HOME="path to your JVM"

export PATH=$JAVA_HOME/bin:$PATH