As we know, it is possible to specify JDK path in gradle.properties at the project level, in property: org.gradle.java.home. However, this file may be under VCS (i.e. git). Users may have different paths for JDK, hence we can't commit this file.
Is there any safe, project-agnostic way to specify this property, so it works for users and different projects? Maybe using some environment property?
EDIT
I am looking a way to specify JDK per project but not be forced to commit this information.
Your wording is a little confusing since if you place the property in a non-VCS location (like an environment variable) it's not really "cross-user" since every user will have to configure this explicitly.
If you simply want to set properties in a way that is outside of version control there are several ways to do this.
Use an environment variable, like you mention. Simply prefix it with ORG_GRADLE_PROJECT_. For example, ORG_GRADLE_PROJECT_javahome would then be available in your build script as javahome.
Place the properties in a file located at USER_HOME/.gradle/gradle.properties.
Specify the property via the CLI with the -P option.
Use something like the Gradle properties plugin to place additional properties in a separate file ignored by VCS.
Related
I want to specify different encoding for different folders in a project but within a single sonar properties file. How to specify the same ?
This is not possible. Note that recent SonarQube versions are doing encoding auto-detection, and are also detecting BOM. If you have a concrete use case that is not supported, I encourage you to expose it on the SonarQube Google group.
Suppose a team in the US has a project containing this local library
<dependency><artifactId>garbage</artifactId></dependency>
but the UK version of our project has a pom.xml with this dependency listed instead:
</dependency><artefactId>rubbish</artefactId><dependency>
which specifies the localised build of the artefact.
Currently, a script takes the garbage project, builds it with UK localisation, but then has to patch up the .jar files after the fact so that the artefactId reflects the localisation, including if the string has been copied as part of the build process. This method has proven to be unreliable, however: Is there a way of migrating to a system which uses Maven, alone, to change the build ID depending on something like the LANG environment variable?
Or; is it not possible to introduce configuration into the pom.xml configuration file itself?
If you need to build a project for different environments, you can use Maven Profiles:
http://maven.apache.org/guides/introduction/introduction-to-profiles.html
You can put different dependencies into different profiles and activate/deactivate the profiles in build process, on the command line or e.g. by marker files.
I want to use allprojects/afterEvaluate in a multiproject build to do something on each project based on properties that it has set. Is there a way to set properties per project in a way that is not inherited by subprojects?
ext.myProp works if I'm only concerned with leaf projects. But if a parent needs to set that property too, I can't find a way to distinguish which project it was set on. The multiproject guide explains that properties are (begrudgingly) inherited.
This mechanism reminds me of prototypal inheritance in JavaScript. Does gradle have a hasOwnProperty equivalent?
I dug some more and found that while there's no general way to isolate which of the several delegated scopes a project property is coming from, if you're specifically looking for an ext property, then there is a has method you can check on a specific project's ext container that does not delegate (at least not to the extent that hasProperty does).
So proj.ext.has('myProp') will be true if a value has been assigned to that project directly.
An important caveat is that properties set via -P or gradle.properties appear to be replicated into the extension containers of all projects automatically, and I don't think there's a way to distinguish that. Extension or task properties might be easier to isolate since they're not inherited, but they're less ad hoc.
Is it possible somehow possible to add a environment variable to the generated scripts say LD_LIBRARY_PATH=$BASEDIR/native/libs/. I did not find anything in the docs. Maybe there will at least be a "hacky" way using another maven plugin?
The simple solution for this is to use a environment setup file which can be configurate in Appassembler within the pom.xml
Is it possible to define different profiles in gradle? I've written a WebApplication and i want to deploy it with the production settings. Furthermore my app is using PrettyFaces. Since i'm using different two languages i also want a language sepcific build. Here is my use case:
production/en, production/ru
The build with a specific language indicates which db to use and which language is the default one. Furthermore the urls (PrettyFaces) are different files. In my opinion i need a different web.xml and a different pretty-faces.xml ?
Thanks in advance!
Here are some options:
Create a task for each setting, so you can do gradle buildEn or gradle buildRu to differentiate the builds. You can write each task manually, or dynamically generate them.
Pass a project property to your build, e.g. gradle build -Plang=ru. Then you can reference lang from your task and do the logic there. Project properties can also be specified in gradle.properties file if you don't like passing the property every time. Anyway check this out.
Probably not what you want, but you can add behaviour to your build if a certain task is present in the build graph (in the example additional logic is executed when graph contains release task).
Good luck