I use a cargo plugin with tomcat8x as container-id on linux.
The maven command cargo:run make jvm using a default logging.properties, which seems to be built by the plugin, and I can see the -Djava.util.logging.config.file=/thePath/conf/logging.properties at the end of the process command (thePath is catalina.base)
This file is a very simple default logging.properties (I can see the comment # Codehaus CARGO, copyright 2004- etc... inside).
I'm trying to use an other -D .... logging.properties via the property <cargo.start.jvmargs> in my pom.xml but it comes at the first position in the process, so the default one is still used.
So how could I do ? Thank you.
Related
I have a really simple java spring-boot gradle application.
When I build an image from source with:
pack build testapp:0.0.1 --builder paketobuildpacks/builder:base
and try to run it with docker I get the following error:
ERROR: failed to launch: determine start command: when there is no default process a command is required.
The generated Entrypoint in this image is "/cnb/lifecycle/launcher".
When I inspect the image with pack inspect-image there are no processes.
I tried this with different java spring-boot gradle applications. When I use the "bootBuildImage" gradle task, it does nearly the same but uses the pre-build .jar-file and the resulting image works. The generated Entrypoint in this image is "/cnb/process/web" and pack inspect-image shows three processes.
Any ideas?
I can't see your build output, but it sounds like you're hitting a known issue. If this is not your problem, please include the full output of running pack build.
Onto the issue. By default, Spring Boot Gradle projects will build both an executable and non-executable JAR. Because this produces two JAR files, it presently confuses the buildpacks.
There are a couple of solutions:
Tell Gradle to not build the non-executable JAR. The buildpack requires the executable JAR. You can do this by adding the following to your build.gradle file:
jar {
enabled = false
}
This is the solution we have used in the Paketo buildpack samples.
If you don't want to make the change suggested in #1, then you can add the following argument to pack build: -e BP_GRADLE_BUILT_ARTIFACT=build/libs/<your-jar>.jar. For ex: -e BP_GRADLE_BUILT_ARTIFACT=build/libs/demo-0.0.1-SNAPSHOT.jar. You can use glob-style pattern matching here, but you need to make sure that what you enter does not match *-plain.jar. That will be the non-executable JAR that gets built by default.
This option just simply tells the Gradle buildpack more specifically what the JAR file to pass along to subsequent buildpacks.
We also have an open issue that should help to mitigate this problem. When the executable-jar buildpack gains support for multiple JARs, it'll be less likely that you'll need to set this. Essentially, this fill will add support so the executable-jar buildpack can inspect and detect an executable JAR, which would allow it to throw out the -plain.jar file since it's not executable.
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.
I want specify the Java home path during building my Android gradle via command line; for example,
gradle build -d path of jdk
Is it possible?
According to gradle documentation:
The following properties can be used to configure the Gradle build
environment:
...
org.gradle.java.home Specifies the Java home for the Gradle build
process. The value can be set to either a jdk or jre location,
however, depending on what your build does, jdk is safer. A reasonable
default is used if the setting is unspecified.
org.gradle.jvmargs Specifies the jvmargs used for the daemon process.
The setting is particularly useful for tweaking memory settings. At
the moment the default settings are pretty generous with regards to
memory.
In other words, you can do it simply by running
gradle build -Dorg.gradle.java.home=<java home path>
Depending on what you want to accomplish, one of the following should work.
As Amnon Shochot suggested, set the -Dorg.gradle.java.home flag. This is probably preferable in most cases.
If you want to have use a particular JDK throughout, set the JAVA_HOME variable appropriately before executing gradle.
$ export JAVA_HOME=/usr/local/specialJava/
$ gradle build
If you don't want to change the environment, try adding the below to your build.gradle script. It should affect only the compiler used to compile Java code, nothing else. So Gradle doesn't run inside this particular JDK, but it will use it for compiling.
tasks.withType(JavaCompile) {
options.fork = true
options.forkOptions.executable = "/usr/local/specialJava/bin/javac"
}
(Last option stolen from here)
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).
I am working on a big projects with many pom.xml files and I need to specify all the libraries that I use. This means that I need to read pom.xml files recursively and get groupId, artifactId, scope and version. I checked out mvn dependency:tree but I can't find a way to print it to a file in a readable format. I saw appendOutput but I saw no example on how to use it in cmd. I saw some solutions done in Linux but I only have access to Windows XP.
This can (at least now) be done with command line options to the dependency:tree plugin.
Try:
mvn dependency:tree -Doutput=/path/to/file
Reference: Maven Dependency Plugin Page
You only asked about "readable" format, but you can also pass the -DoutputType parameter with various options. Also note that the version I have installed, I get the following warning:
[WARNING] The parameter output is deprecated. Use outputFile instead.
So, consider trying it with -DoutputFile=/path/to/file
Also, I was unable to get the -DoutputType paramater to give me anything other than the default text, but didn't have a chance to play around with it. YMMV.
If you have multiple modules under the same repo/project and want the dependencies of all the modules in one file, so as to be able to diff b/w one build and another to see if something changed somewhere, you can do
$project_dir> mvn dependency:tree -DoutputFile=<absolute_path_to_file> -DappendOutput=true
e.g.
$project_dir> mvn dependency:tree -DoutputFile=`pwd`/mvn_dependency_tree.txt -DappendOutput=true
See other options available at https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html
Adding the
<plugin>
<groupId>org.apache.servicemix.tooling</groupId>
<artifactId>depends-maven-plugin</artifactId>
</plugin>
plugin produces a classes/META-INF/maven/dependencies.properties file with the project dependencies easily parseable.
Example of the output produced:
# Project dependencies generated by the Apache ServiceMix Maven Plugin
# Generated at: Mon Oct 10 17:43:00 CEST 2011
groupId = my.group.name
artifactId = my.artifact.name
version = 0.0.1-SNAPSHOT
my.group.name/my.artifact.name/version = 0.0.1-SNAPSHOT
# dependencies
junit/junit/version = 4.8
junit/junit/type = jar
junit/junit/scope = test
org.easymock/easymock/version = 2.4
org.easymock/easymock/type = jar
org.easymock/easymock/scope = test
On GNU/Linux I would just do mvn dependency:tree > myFile. However, if you're restricted to Windows only, than I would look for Windows' syntax for streaming the output of a command.
According to this site (just a top-results from Google) it seems that Windows' console also use > sign to direct the output stream to i.e. a file.
So would you mind trying this?
I have run the below command and got the file having all the maven dependency.
mvn dependency:tree -DoutputFile=temp/mvn_dependency_tree.txt
This command will create a folder named "temp" and inside this folder a file name mvn_dependency_tree.txt will be created with all the dependencies.
You can always install MinGW and MSYS and then use the Linux examples using dependency:tree in Windows
Perhaps effective-pom (in conjunction with some linux commands for saving the file) can be sufficient for your needs.