Ant set platforms.JDK_1.6.home without parameter - windows

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%"

Related

Disabling Gradle daemon in a specific project

I'd like to build certain projects without the use of of Gradle daemon. I've read that this can be done either by command-line argument --no-daemon or by changing Gradle properties under .gradle/. I need to disable it for just some of the projects I build under the root project though.
Is it possible via settings.gradle/build.gradle settings or am I better off making custom build script?
You can simply add org.gradle.daemon=false to a gradle.properties file in the project root folder.
The daemon documentation mainly talks about disabling the daemon altogether on a machine but the gradle properties documentation indicates that the location where a property / value pair is declared is irrelevant, they are sourced from different location, with overwrite rules.

Providing system properties via command line with dot in the name in Gradle

We are migrating our project from Maven to Gradle. Our CI uses system properties like -Dwebdriver.type=firefox to set certain behaviour thus we don't want to hardcode such props in gradle.properties file etc. Is there a way to provide a system property with a dot in the name using command line?
If you run the following:
build.gradle:
logger.lifecycle("some.property ${System.properties['some.property']}")
with:
gradle -Dsome.property=lol
It should give you the expected output.

How can I make “gradle --console=rich” the default?

Along the lines of this answer (which works for me, BTW) and the javadocs, I tried
gradle.startParameter.consoleOutput = org.gradle.api.logging.configuration.ConsoleOutput.Rich
in my ~/.gradle/init.gradle. However, I still need --console=rich to get color output. Why?
Tested with Gradle 2.14.1 and 3.2.1.
Terminal is cygwin urxvt with TERM variable set to rxvt-unicode-256color.
Since Gradle 4.3 you can use org.gradle.console property in gradle.properties:
org.gradle.console=rich
A new console verbose mode will print outcomes of all tasks (like UP-TO-DATE) like Gradle 3.5 and earlier did. You can set this via --console=verbose or by a new Gradle property org.gradle.console=(plain rich verbose).
I am not sure if you can force the rich console from a gradle script, as the detection happens likely before the script is interpreted.
NativeServices class provides the integration with the console. If you look at the source code, there are two messages possibly printed in log:
Native-platform terminal integration is not available. Continuing with fallback.
Unable to load from native-platform backed ConsoleDetector. Continuing with fallback.
The latter might give you more information why. Try running the gradle script with --debug. You will likely find out that you are missing a native library that is either not available in cygwin or it is, but is not on library path.
I believe it works when you specify the rich console from the command line, because gradle forces the colours even though the console doesn't indicate it supports them.
Does it work if you don't use the cygwin console in Windows native command line or maybe GitBash?
There is a workaround how you can make this work. You can create an alias in cygwin that will always add the --console=rich.
If you are using gradle wrapper, you can edit the gradlew script and add the command line parameter. To make it automated, you can change the wrapper task to alter your script in the doLast part.
Create a file called gradle.properties inside your ~/.gradle/ folder.
Inside gradle.properties, add the line org.gradle.console=rich.
Each builds will run under --console=rich automatically because the new gradle.properties will be merged with the gradle.properties of your project.
If your project's gradle.properties contains the same tag as the local file, your project's will be used overriding the local file's
If you are on Linux/Mac set
alias gradle='gradle --console rich'
in your ~/.bashrc.
In Gradle Wrapper, add the following line:
org.gradle.console=rich
to ./gradle.properties in the root folder, where the gradlew script is located.

Activate a profile based on environment

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).

Does Maven Have a mechanism to read the machine name

I'm writing a Maven project and I'd like to include a file in the generated WAR that will contain some build time information. Typically this will be things like
The build time/date stamp
The user name of the person who built the WAR
The version of the app as specified in the POM
These are all fairly easy as there are maven properties which will give me the information I need.
I'd also like to include the machine name. I know Windows stores this information in an environment variable called "COMPUTERNAME", while *nix uses the hostname command.
Is there some platform independent way of grabbing this information so that I can write it into my text file?
I did this by invoking the Maven Ant task. Within that I used the following Ant tasks:
<tstamp> to generate a timestamp property
<propertyfile> to create a properties file containing properties like the above timestamp, the username etc.
You could use the Ant <exec> task to execute hostname and nominate an output property to write this value into.
This created a properties file in the src/main/resources dir that I then embedded in the .war file
As Andrew Logvinov says,
Look up hostname from Maven
Thanks :-)

Resources