What are the environment variables required by a developer to ensure maven is setup correctly on a machine? are M2_HOME, MAVEN_HOME, MVN_HOME and MVN_OPTS all the same?
All you need to set is JAVA_HOME pointing to a JDK installation. The first three do not exist anymore in master. The latter is options passing args to the JVM.
Related
Is there a way to tell SBT which (locally) installed JDK to use?
I am quite certain I could change PATH and JAVA_HOME but I'd rather not change those settings since they apply for the whole system (Windows in that case).
I am more looking for a command line parameter of some sort.
If you're looking to specify a JDK for running SBT (rather than a JDK to use for running your code and/or tests from within SBT), you can make use of the JAVA_HOMES environment variable, plus a .java-version file in your project.
This is described in SBT's sbt.bat file (typically installed to C:\Program Files (x86)\sbt\bin) as a "poor man's jenv", which isn't currently available on Windows.
(If you're looking for a similar solution for Linux or MacOS, you can either use jEnv, or specify the Java home directory via the -java-home SBT command line option—which also, sadly, isn't currently implemented on Windows.)
The JAVA_HOMES environment variable (not to be confused with JAVA_HOME) is used by SBT to identify a directory that contains one or more JDK installations. For example, if you're using AdoptOpenJDK's JDK distributions (recommended on Windows, if Oracle's new licensing restrictions are a problem for you), then this would typically be defined as C:\Program Files\AdoptOpenJDK.
Let's say that you have two such JDK installations in the JAVA_HOMES directory: one in a subdirectory named jdk-8.0.212.03-hotspot; another in the jdk-11.0.3.7-hotspot subdirectory. You can select which JDK you want to use, on a project-by-project basis, by creating a file called .java-version in the root directory of each SBT project. To use the JDK in the jdk-8.0.212.03-hotspot subdirectory, this file should then contain:
jdk-8.0.212.03-hotspot
When you run the sbt command, if you have JAVA_HOMES defined, SBT will look for a .java-version file in the project's root directory. If it finds it, it creates a local version of JAVA_HOME that is defined as JAVA_HOMES plus the last line of .java-version. It also adds this JAVA_HOME's bin directory to the path. (It also creates a JDK_HOME process-local environment variable with the same value.)
This should do what you want. Although it's not a command line-based solution, it doesn't adversely affect other users, and allows each SBT project to be configured individually. If you do not have permission to create a system-wide environment variable, you should still be able to create a user-specific JAVA_HOMES environment variable. Note that when using this solution, the JDK that SBT uses is then not necessarily the one identified by your system-wide (or user-specific) JAVA_HOME environment variable. (If you have not defined JAVA_HOMES, then SBT will expect you to have defined a valid JAVA_HOME variable.)
One word of caution: if you commit .java-version to source control, you must ensure that everyone defines a valid JAVA_HOMES environment variable, and has a JDK with the exact same name installed in that directory.
I faced the issue with the surefire plugin "2.19.1" as below. I have tried with the version 2.19.1,2.12.4,3.0.0-M1
You're maven seems to be corrupt. Assuming you're on a windows machine:
1) set M2_HOME environment variable to the folder where maven is. (if in doubt download it and put it somewhere, it's just a java program.
2) set JAVA_HOME environment variable to the folder where your java is.
3) add %JAVA_HOME%/bin:%M2_HOME%/bin to the start of your PATH environment variable.
4) Make sure your ~/.m2/ folder has a settings.xml in it, you can use the one from the maven download to start. (you may need to add the proxy details)
5) Test with
mvn -version
6) You can clear your local repository by deleting files in ~/.m2/repository if you've not done much and have a reasonable network just blow the whole thing away.
I am currently trying to get my Jenkins (version 2.35) Jobs for AEM (6.2) author/publishers up and running. In this setup I have Dev, Staging and Production environments. To avoid version controlling my credentials in my pom.xml I have made the use of environment variables in maven (version 3.3.9).
<properties>
<aem.host>localhost:4502</aem.host>
<aem.protocol>http</aem.protocol>
<aem.user>${env.AEM_AUTHOR_USER}</aem.user>
<aem.password>${env.AEM_AUTHOR_PASSWORD}</aem.password>
</properties>
On my local environment I have tested setting those environment variables to the correct and then incorrect values and it behaves as one would think it would.
The thing here is that when I build the Dev Author job on my Jenkins server, it seems to succeed whether the environment variables are set to the correct values or not. It is so weird and at this point I have no clue to what is going on. I am setting the environment variables on the Jenkins server via a simple.
source ~/path/to/file
Where ~/path/to/file would look something like the following:
AEM_AUTHOR_USER="admin"
AEM_AUTHOR_PASSWORD="admin"
Also I should mention that previously to using environment variables in maven I had the AEM credentials directly in the pom.xml just for Dev jobs.
I'm wondering if Jenkins has cached the maven properties thus the credentials and re-setting the environment variables has no effect. I should also mention I have tried re-creating the workspace on each new build to see if it would clear some caching system but no dice.
Is Jenkins or Maven caching my maven properties somewhere that my environment variables are being ignored ?
Has anyone ran into the issue I am describing ?
Should I be using the EnvInject Plugin Jenkins plugin ?
Any help is welcomed.
Thanks,
Nicola
In the case of my Develop Jobs it seems that Jenkins uses some sort of caching system that I wasn't able to clear. Even after deleting the workspace or deleting the cache folder in
/home/jenkins/.jenkins/cache
Anyways after trying a lot of things to attempt regaining control over the value of the AEM credentials set in my pom.xml I figured out how to control the values of the pom.xml environment variables which solved my problems. The way I did that was to install the EnvInject Plugin after which I was able to configure my maven environment variables individually on all my jobs. Everything works great now.
I'm using Gitlab CI to deploy TYPO3 projects onto a target server and I'm trying to remove the PackageStates.php from the git repository and generate it on the target server with EXT:typo3_console instead.
But I need to set the TYPO3_ACTIVE_FRAMEWORK_EXTENSIONS environment variable in order to have the necessary system extensions loaded.
How do I set this ENV variable?
What's a good way to store these information in my project to have it available in the deployment process? I could use Gitlab variables but I feel like this information should be included in the git repository.
You don't need to set and use the env variable if you don't want to. You can just require the TYPO3 core extensions you need in any package of your project and typo3_console will take care to populate the environment variable for you as needed during composer install time.
If you want to, you can however still override this env var from command line for individual calls.
EDIT: This feature has been integrated in typo3_console 3.3.0
I know I can't set environment variable directly from Gradle, but is there some other solution?. I need to do this:
do some stuff..
set 4 environment variables (their values depend on some settings)
run some ant scripts (that depend on environment variables)
I thought of creating a file (.setenvironment) with all the settings I need, and then source it from Gradle (source .setenvironment), but I fear that I wouldn't be able to reset the variables if something goes wrong (and I need to set "JAVA_HOME", for instance, which is also important for the build scripts themself).
You can't set environment variables from java and other JVM languages. The only way of doing it is via ProcessBuilder.
You can also set the variables before gradle is run.