I want to change the log level for a particular maven plugin, ideally from within the pom.xml, less than ideal but still acceptable by a command line switch.
In particular I want INFO in general but only WARN from maven-shade-plugin:3.1.0.
You can configure it with simplelogger.properties file. Add following line to the properties file located at {maven.home}/conf/logging/simplelogger.properties
org.slf4j.simpleLogger.log.org.apache.maven.plugins.shade=warn
Info level is the default level for all loggers, which is also set at properties file (If you want to change it in the future)
org.slf4j.simpleLogger.defaultLogLevel=info
If you want to do it with command switch you can add following to your maven command. (I prefer modifying properties file)
-Dorg.slf4j.simpleLogger.log.org.apache.maven.plugins.shade=warn
Related
I am working on a project where there is a different gradle.properties file for each environment. The process seems to be to rename gradle.properties.env (for example) to gradle.properties as required.
I am new to Gradle so possibly this is the wrong approach more broadly, but for now, is there a way to tell ./gradlew to use a specific file as its gradle.properties e.g.
./gradlew --propertiesfile=gradle.properties.env
It is probably better to put the environment-specific property file in the GRADLE_USER_HOME folder (defaulting to $USER_HOME/.gradle). Configurations in this location take priority over the ones in the project folder.
Another option is to supply the individual properties as system properties or environment variables.
My project structure looks like as attached file. Even though I have profile specific properties, I would like to run my app with external properties file i.e., outside of jar file.
I tried with following command:
java -jar test_service.jar --spring.config.location=file:///C:/external_props/test.properties
But its taking application-default.properties file.
from log file:
No active profile set, falling back to default profiles: default
Why it is not taking external properties file ?
When you pass --spring.config.location command line argument SpringBoot won't consider application-*.properties files in src/main/resources directory. The filename you mentioned for --spring.config.location is taken as base filename, in your case test. So, it will only load test.properties file from that path you provided as default profile.
If you want to enable certain profile, say prod, you need to create file C:/external_props/application-prod.properties and enable prod profile using --spring.profiles.active=prod.
Spring will automatically look for some property file in a specific location.
From where you execute the jar file, Spring will look in that directory for a property file called application.properties
An other way is to put a config directory in the directory you execute the jar from and put the application properties in there.
There is one more option and that is the -Dspring.profiles.active={profiles} parameter.
Spring will then look in the directory or config directory to application-{profile}.properties
Reference:
https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html
Also i think you use the
--spring.config.location=file:///C:/external_props/test.properties
is not used correctly for a windows based file path.
Windows uses the \ instead of the /.
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.
Due to the configuration I'm using, I get lots of these:
[WARNING] 'dependencies.dependency.systemPath' for local-deps:[...] should not point at files within the project directory, ${basedir}/[...] will be unresolvable by dependent projects [...]
Since this is how the application is currently setup, I can't fix them; but they clutter the console, so is there a way to disable them? mvn --quiet is not an option because it removes too many messages.
See the Maven 3.1.x logging documentation. You can configure the log level by editing the ${M2_HOME}/conf/logging/simplelogger.properties file. First set the value of org.slf4j.simpleLogger.showLogName to true and you will see the logname that prints your unwanted message. After that add the line org.slf4j.simpleLogger.log.a.b.c=error where a.b.c is the logname.
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).