When I try to build a maven project on eclipse, I get this error:
-Dmaven.multiModuleProjectDirectory system property is not set.
Check $M2_HOME environment variable and mvn script match.
Set MAVEN_OPTS = -Dmaven.multiModuleProjectDirectory
If you are developing application on Eclipse RCP and trying to build any project using any procedure (e.g. embedded maven -- by creating your own launch configuration file), then you will have to set "MavenLaunchConstants.ATTR_POM_DIR" attribute, provided the value of project path.
Code for reference :
ILaunchConfigurationWorkingCopy workingCopy = launchConfigurationType.newInstance(launchFileFolder, launchFileName); workingCopy.setAttribute(MavenLaunchConstants.ATTR_POM_DIR, <project_path>);
Related
In our CI environment, we currently have one build server (based on Atlassian Bamboo) and two SonarQube instances (versions 6.0 and 6.5). Initially, our CI server was configured to communicate with the 6.0 SonarQube instance. This has been configured in the /home/bamboo/.gradle/gradle.properties file on our CI server like this:
systemProp.sonar.host.url=<http url of SonarQube 6.0 instance>
systemProp.sonar.login=<username here>
systemProp.sonar.password=<password here>
Now we have another Gradle-based project running on our CI server which shall talk to the new SonarQube 6.5 instance. I tried configuring this but failed all the time.
Things I have done so far:
Added commandline arguments to gradle wrapper command:
I have tried adding -Dsonar.host.url=, -Dsonar.login=, -Dsonar.password= to the Gradle command. As this didn't seem to work, I have also tried to set commandline arguments as SonarQube system properties using -DsystemProp.sonar.host.url=, -DsystemProp.sonar.login=, -DsystemProp.sonar.password=. This didn't work either.
Added properties to the build.gradle file
- Added properties to the build.gradle file like this:
sonarqube {
properties {
property "sonar.host.url", "<http url of SonarQube 6.0 instance>"
property "sonar.login", "<username here>"
property "sonar.password", "<password here>"
...<other SonarQube analysis settings here>...
}
}
In all cases, the CI server talked to the wrong SonarQube instance (6.0). My question is, whether it is possible to configure a single project to talk to another SonarQube instance. As you have seen, we use Gradle 3.2.1 as a build tool. And we are using the org.sonarqube Gradle plugin too.
Thank you for any help.
André
Your first try did not work, because you set the system properties from the commandline, but setting it from the project properties later on resets the system properties to the configured values.
Your second try did not work, because the systemProp.sonar.login syntax is only suppored in gradle.properties files, not via -P commandline project properties.
Your third try did not work because the SonarQube scanner prefers the system property values over the value configured via the DSL, so that one can change what is configured in the build script with the help of local configuration.
You need to set the system properties in your build script manually, this then overwrite what was automatically set from the project property. Using the project gradle.properties file does not work as the user file overwrite the project file. So you need something like System.properties.'sonar.login' = '...' in your build script. You can either hard-code it there, or then use project properties that you can set in your gradle.properties file or via -P parameters.
Besides that, I'd never depend on having any configuration in Gradle User dir on a build server. Most buildservers use build agents that might run on distributed machines, so you would always have to make sure that all build agents are configured the same and so on. I'd always configure in the build setup of the build server the according configuration, either by setting system properties, or environment properties or commandline arguments.
Just my 2ct.
In JDeveloper 12.1.3 get 'suddenly' follwing error when running any maven goal on a random Java application. I mean suddenly, because i use JDeveloper infrequently for making modifications to Java classes and do not have full control over my Development environment. (Managed by admins).
Most important env variables are;
M2 = %M2_HOME%\bin
M2_HOME = D:\Tools\apache-maven-3.3.9
MAVEN_HOME = D:\Tools\apache-maven-3.3.9
MAVEN_OPTS = -Xms256m -Xmx512m -Dmaven.multiModuleProjectDirectory=%MAVEN_HOME%
I also tried enclose %MAVEN_HOME% in double quotes.
Maven preferences in JDeveloper are
Maven Version, external version: D:\Tools\apache-maven-3.3.9
User settings: D:\Tools\apache-maven-3.3.9\conf\settings.xml
Additional settings: -X -DdownloadSources=true -DdownloadJavadocs=true -P deploy-to-local-server -Dmaven.multiModuleProjectDirectory=D:\Tools\apache-maven-3.3.9
Local Repository: D:\Tools\Apache\maven3_repository
Index Directory: D:\Tools\Apache\maven3_index
All settings seems to be ok. When running mvn from the commandline, e.g. mvn test --settings D:\Tools\apache-maven-3.3.3\conf\settings.xml the build completes successfully.
Als tried to set the Java property in the jdev.conf AddVMOption -Dmaven.multiModuleProjectDirectory="%MAVEN_HOME%"
If the mvn goal test is chosen in JDeveloper it executes the command;
D:\Oracle\Java\jdk1.7.0_45\bin\javaw.exe -classpath D:\Tools\apache-maven-3.3.9\boot\plexus-classworlds-2.5.2.jar;D:\Tools\apache-maven-3.3.9\lib\wagon-provider-api-2.10.jar;D:\Tools\apache-maven-3.3.9\lib\wagon-http-shared-2.10.jar;D:\Tools\apache-maven-3.3.9\lib\wagon-http-2.10-shaded.jar;D:\Tools\apache-maven-3.3.9\lib\wagon-file-2.10.jar;D:\Tools\apache-maven-3.3.9\lib\slf4j-simple-1.7.5.jar;D:\Tools\apache-maven-3.3.9\lib\slf4j-api-1.7.5.jar;D:\Tools\apache-maven-3.3.9\lib\plexus-utils-3.0.22.jar;D:\Tools\apache-maven-3.3.9\lib\plexus-sec-dispatcher-1.3.jar;D:\Tools\apache-maven-3.3.9\lib\plexus-interpolation-1.21.jar;D:\Tools\apache-maven-3.3.9\lib\plexus-component-annotations-1.6.jar;D:\Tools\apache-maven-3.3.9\lib\plexus-cipher-1.7.jar;D:\Tools\apache-maven-3.3.9\lib\org.eclipse.sisu.plexus-0.3.2.jar;D:\Tools\apache-maven-3.3.9\lib\org.eclipse.sisu.inject-0.3.2.jar;D:\Tools\apache-maven-3.3.9\lib\maven-settings-builder-3.3.9.jar;D:\Tools\apache-maven-3.3.9\lib\maven-settings-3.3.9.jar;D:\Tools\apache-maven-3.3.9\lib\maven-repository-metadata-3.3.9.jar;D:\Tools\apache-maven-3.3.9\lib\maven-plugin-api-3.3.9.jar;D:\Tools\apache-maven-3.3.9\lib\maven-model-builder-3.3.9.jar;D:\Tools\apache-maven-3.3.9\lib\maven-model-3.3.9.jar;D:\Tools\apache-maven-3.3.9\lib\maven-embedder-3.3.9.jar;D:\Tools\apache-maven-3.3.9\lib\maven-core-3.3.9.jar;D:\Tools\apache-maven-3.3.9\lib\maven-compat-3.3.9.jar;D:\Tools\apache-maven-3.3.9\lib\maven-builder-support-3.3.9.jar;D:\Tools\apache-maven-3.3.9\lib\maven-artifact-3.3.9.jar;D:\Tools\apache-maven-3.3.9\lib\maven-aether-provider-3.3.9.jar;D:\Tools\apache-maven-3.3.9\lib\jsr250-api-1.0.jar;D:\Tools\apache-maven-3.3.9\lib\jsoup-1.7.2.jar;D:\Tools\apache-maven-3.3.9\lib\javax.inject-1.jar;D:\Tools\apache-maven-3.3.9\lib\guice-4.0-no_aop.jar;D:\Tools\apache-maven-3.3.9\lib\guava-18.0.jar;D:\Tools\apache-maven-3.3.9\lib\commons-lang3-3.4.jar;D:\Tools\apache-maven-3.3.9\lib\commons-lang-2.6.jar;D:\Tools\apache-maven-3.3.9\lib\commons-io-2.2.jar;D:\Tools\apache-maven-3.3.9\lib\commons-cli-1.2.jar;D:\Tools\apache-maven-3.3.9\lib\cdi-api-1.0.jar;D:\Tools\apache-maven-3.3.9\lib\aopalliance-1.0.jar;D:\Tools\apache-maven-3.3.9\lib\aether-util-1.0.2.v20150114.jar;D:\Tools\apache-maven-3.3.9\lib\aether-transport-wagon-1.0.2.v20150114.jar;D:\Tools\apache-maven-3.3.9\lib\aether-spi-1.0.2.v20150114.jar;D:\Tools\apache-maven-3.3.9\lib\aether-impl-1.0.2.v20150114.jar;D:\Tools\apache-maven-3.3.9\lib\aether-connector-basic-1.0.2.v20150114.jar;D:\Tools\apache-maven-3.3.9\lib\aether-api-1.0.2.v20150114.jar; -Dclassworlds.conf=D:\Tools\apache-maven-3.3.9\bin\m2.conf -Dmaven.home=D:\Tools\apache-maven-3.3.9 org.codehaus.classworlds.Launcher -X -DdownloadSources=true -DdownloadJavadocs=true -P deploy-to-local-server -Dmaven.multiModuleProjectDirectory=D:\Tools\apache-maven-3.3.9 --settings D:\Tools\apache-maven-3.3.9\conf\settings.xml --file C:\Projecten\project\A\B\pom.xml clean -Denv.ORACLE_HOME=D:\Oracle\Middleware_JDev12.1.3
When executing this command on the commandline it completes, but does not seem to execute to goal. If javaw is replace with java it shows the error -Dmaven.multiModuleProjectDirectory system property is not set. Check $M2_HOME environment variable and mvn script match. again. As can be seen in de command extract above, the system property is set.
Any other suggestions ?
Downgrading Maven to 3.1.1 resolved the issue. For now this is a solution for me.
Is there an ANT equivalent basedir property in gradle?
${basedir}
I am trying to get the name of the directory where the build script is located.
Thank you in advance!
Depending on your exact needs, you could use buildFile.parent or projectDir. (The build file path defaults to "$projectDir/build.gradle" and can be reconfigured in settings.gradle.) See the Gradle Build Language Reference for which properties and methods are available on Project and other classes.
I'm having a problem trying to run ant on a windows machine. I get the following error:
BUILD FAILED
C:\Users\USER\testing\mercurial\project\NetbeansProject\nbproject\build-impl.xml:111: The J2SE Platform is not correctly set up.
Your active platform is: JDK_1.6, but the corresponding property "platforms.JDK_1.6.home" is not found in the project's properties files.
Either open the project in the IDE and setup the Platform with the same name or add it manually.
For example like this:
ant -Duser.properties.file=<path_to_property_file> jar (where you put the property "platforms.JDK_1.6.home" in a .properties file)
or ant -Dplatforms.JDK_1.6.home=<path_to_JDK_home> jar (where no properties file is used)
If I execute ant -Dplatforms.JDK_1.6.home=%JAVA_HOME% it executes fine, but, is there some way to avoid adding this parameter every time I need to build a program?
I don't think it's possible to set ant properties outside of command line or properties files loaded explicitly by the build script.
If you are looking for a less verbose way to launch ant, try using either a wrapper .bat file, or assigning an alias doskey ant=ant "-Dplatforms.JDK_1.6.home=%JAVA_HOME%"
Here's my scenario:
Maven 2.0.9 is our build system
We install code to multiple environments
All of our environment-specific properties are contained in property files, one for each environment
We currently read these properties into maven using the properties-maven-plugin; this sub-bullet is not a requirement, just our current solution
Goal:
Perform certain parts of the build (ie. plugin executions) only for certain environments
Control which parts are run by setting values in the environment-specific property files
What I've tried so far:
Maven allows plugins executions to be put inside pom profiles, which can be activated by properties; unfortunately these must be system properties - ie. from settings.xml or the command-line, not from properties loaded by the properties-maven-plugin
If possible, we'd like to keep everything encapsulated within the build workspace, which looks something like this:
project
pom.xml
src
...
conf
dev.properties
test.properties
prod.properties
build-scripts
build.groovy <-- the script that wraps maven to do the build
install.groovy <-- ... wraps maven to do the install
Running a build looks like:
cd build-scripts
./build.groovy
./install.groovy -e prod
Is there any possible way to accomplish these goals with the version of maven we are using? If not, is it possible with a newer version of maven?
This isn't possible using just Maven. (See also How to activate profile by means of maven property?) The reason is that profiles are the first thing evaluated before anything else to determine the effective POM.
My suggestion is to write some preprocessor that parses your environment specific property files and converts them to the required system properties before launching Maven. This script can be included in your ~/.mavenrc so that it runs automatically before Maven is launched. Here is an example script that that assumes the properties file is in a fixed location:
properties=`cat /etc/build-env.properties`
while read line; do
MAVEN_OPTS="$MAVEN_OPTS -D$line"
done <<< "$properties"
If the properties file is not fixed, you'll just need to add something to the script to discover the location (assuming it is discoverable).