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.
Related
I already searched and found out that you can create a profile and a plugin that will run only for that profile, then in build you can specify that it will include that profile.
Unfortunately, for my case, it won't work, because I have a plugin that must run everytime, and I want to be able to specify a flag so it won't execute.
I already thought on adding a global profile (that would be active by default) to execute the plugin, and when I want the plugin to not be executed, disable it with flag -P !profile_id, but it doesn't seem as a good idea because I want to be able to share my code and pom and it should work for every other developer and don't force them on creating this active profile.
If I launch
mvn clean
I am getting zero output, as if I demand only for WARNING only
But I have the default simplelogger.properties file:
org.slf4j.simpleLogger.defaultLogLevel=info
org.slf4j.simpleLogger.showDateTime=false
org.slf4j.simpleLogger.showThreadName=false
org.slf4j.simpleLogger.showLogName=false
org.slf4j.simpleLogger.logFile=System.out
org.slf4j.simpleLogger.cacheOutputStream=true
org.slf4j.simpleLogger.levelInBrackets=true
org.slf4j.simpleLogger.log.Sisu=info
org.slf4j.simpleLogger.warnLevelString=WARNING
I have tried to put defaultLogLevel and warnLevelString to DEBUG, WARN( I had noticed difference in behaviour for that writing before) and info. But always I have the same zero output.
mvn -X
gives the correct debug level of output, but I don't need it, I need normal info level, and what is the most important, I want maven to behave up to the configuration. What could happen?
Restarts and Maven erasing and reinstalling were tried.
If I introduce into the project something that causes a warning, I see it in the output. The same for the error. It seems that Maven remembers somehow that logger was set to WARN level sometimes (and it really was) and cannot forget and change that state.
I had set the
MAVEN_OPTS= -Dfile.defaultLogLevel="WARN"
It overcomes the settings in the simplelogger.properties file.
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
I'm having issues with a test, which when executed in maven fails to initialize log4j, although a valid log4j.properties is in src/test/resources and therefore should end up on the classpath of the test. But it doesn't, i.e. log4j prints only
log4j:WARN No appenders could be found for logger (org.springframework.test.context.junit4.SpringJUnit4ClassRunner).
log4j:WARN Please initialize the log4j system properly.
In order to debug the problem I printed the classpath from the test itself, using the code here
But instead of a lengthy list of jars and paths I just get
/<projectpath>/target/surefire/surefirebooter6226797341642271676.jar
So my questions are:
WTF is maven doing with the classpath?
Why doesn't my log4j.properties end up on the classpath?
How do I debug this?
Note: In Eclipse I can run the test just fine and everything works as expected.
Another note: the maven project is a multimodule project and I'm only executing a single test from a single submodule, with a commandline like this:
mvn -U -Dtest=de.company.project.SomeTest clean test
Have a good look at the maven-surefire-plugin. By default it creates a jar stuffed with your entire classpath. This is controlled by the useManifestOnlyJar option. This works around the problem of Windows having a classpath limit of 1024 (quoting off the top of my head). Under Linux you wouldn't really feel this pain much as the limit is much higher.
If you are forking the maven-surefire-plugin, it will use a different classpath than the one you're running Maven (and the compilation).
Debugging this kind of crappy situation can be done as follows:
In one of your tests add a loop that lists all the environment variables along with the java system properties.
Debug the tests:
mvn -Dmaven.surefire.debug="-Xdebug \
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=9001 \
-Xnoagent" \
test
I found the answer to question 1.
Maven creates the jar with the weird name on the fly and just puts a MANIFEST.MF file in there. That file contains the classpath, and the main class to be started.
This also answers to some extend question 3.
You can copy that jar file somewhere else, while maven is running, so it does not delete it once it is finished. Then you can examine it as long as you want. Turns out my log4.properties is on the classpath (the target directories for the testclasses is there and the properties files is in that directory ....)
Leaves me with question 2.
It turned out somewhere in the forest of pom.xmls the system property log4j.configuration was set to a rather useless value. Setting that value back to the propervalue as described here solved my immediate problem.
Now I just have to find the broken spot in our poms, but that's a story for a different day.
I have a script on Jenkins CI which optionally does dependency:go-offline. The other option should be to do nothing. But I can't put "" in there - it must be a goal.
So - which one would you pick? It should:
Be in central, always reachable
Take minimum time
Have minimal output
Have no side effects
I was thinking of some help:... goal but those tend to have a lot of output. Any better?
You can use this goal and option:
mvn --quiet help:help
the -q,--quiet option causes the output to only show errors.
Note that Jenkins allows you to add options like --quiet as diplayed in the usage: mvn [options] [<goal(s)>]. You configure these in the Jenkins job’s “Goals and options” field.
Check mvn --help output for further information.
I know this is an old question, but I came across it when I had the same requirement and it's still unanswered, so I'm posting for anyone who needs it in future.
This still depends on the current project, but could be useful if you don't want to hardcode a specific plugin for some reason:
mvn -pl ./ validate
-pl ./ means only current project, ignore submodules. Alternatively you could specify specific project by relative path or [groupId]:artifactId.
validate is the first phase of the Default Lifecycle. Doesn't change or build anything.
Alternatively, if you don't have a maven project at all, some maven plugins, or rather specific plugin goals, can be executed without it. E.g.:
mvn org.apache.maven.plugins:maven-dependency-plugin:2.1:help
It would still scan projects if it sees a POM in the current directory. And of course you still need to have the plugin in your local repository.