We have been using Liquibase successfully for about six months. I'm moving to a new CI/CD pipeline using CircleCI and running into an error when running liquibase update over SSH.
Here's the command (after many iterations and much exploration of Liquibase documentation):
ssh $SSH_USER#$TEST_JOB_SSH_HOST "cd /var/www/html/liquibase ; liquibase --url=jdbc:$TEST_DB_URL/$TEST_DB_SCHEMA?user=$TEST_DB_USERNAME --username=$TEST_DB_USERNAME --password="\""$TEST_DB_PASSWORD"\"" --changelog-file=cl-main.xml --search-path=.,./ update --log-level 1"
The result:
However, the file does exist and can be seen here:
It was successfully executed several months ago using our old approach. Now I think Liquibase is just parsing files and somehow failing, likely because it's running from a different directory.
Here's a snippet from the changeset file:
<sqlFile dbms="mysql, mariadb"
encoding="UTF-8"
endDelimiter=";"
path="/../data/regional_integration_details-ingest_day-01.sql"
relativeToChangelogFile="true"
splitStatements="true"
stripComments="true"/>
I think the issue is the leading slash.
The command I pasted above was based on reviewing this help document: https://docs.liquibase.com/concepts/changelogs/how-liquibase-finds-files.html
I'm struggling with the proper syntax to include in the --search-path parameter -- if that's even the correct parameter -- to make this work.
The nuclear option (yet to be tested) is to update all of our changesets, removing the leading slash. I'd prefer not to go that route.
Suggestions?
Edit 1
Updating to mention that the first four changesets are parsed successfully. They have path values like ../dirname/sqlscript_00.sql. Liquibase chokes on the first script with /../dirname/sqlscript_01.sql.
Also, we have no problems running Liquibase in local development, when we cd to /var/www/html/liquibase in our Docker containers and execute the liquibase update command.
Edit 2
Having CircleCI SSH directly into the server doesn't work, as it doesn't carry the variables over with it.
Passing the commands via SSH preserves those variables.
Liquibase removed support for absolute paths in v4.x.
I am attempting to execute my tests using the karate stand-alone jar. Throughout my project, I use the read('classpath:') when locating files.
However, when I attempt to execute my tests from the CLI, I receive the following error:
src.test.java.Users.getUser: -unknown-:6 - javascript evaluation failed: read('classpath:commonUtils.feature'), java.io.FileNotFoundException: commonUtils.feature (The system cannot find the file specified)
Command: java -jar -Dkarate.config.dir="src/test/java" karate.jar -e DEV -t #tests src/test
It seems that I will have to declare the classpath on execution, would you be able to provide some insight on how to do this please? I'm not sure whether my issue is linked to [karate][standalone] Error : could not find or read file
Can you try the ZIP release and if you open the karate batch file you will see this:
java -cp karate.jar:. com.intuit.karate.Main $*
So the trick to setting a custom classpath is to use the com.intuit.karate.Main entry point and in the above example the current dir is also added to the classpath.
It would be great if you try the current RC version (0.9.5.RC3) to ensure we have everything working as expected.
For more information, see this part of the docs: https://github.com/intuit/karate/tree/develop/karate-netty#custom-classpath
I am attempting to execute my tests using the karate stand-alone jar. Throughout my project, I use the read('classpath:') when locating files.
However, when I attempt to execute my tests from the CLI, I receive the following error:
src.test.java.Users.getUser: -unknown-:6 - javascript evaluation failed: read('classpath:commonUtils.feature'), java.io.FileNotFoundException: commonUtils.feature (The system cannot find the file specified)
Command: java -jar -Dkarate.config.dir="src/test/java" karate.jar -e DEV -t #tests src/test
It seems that I will have to declare the classpath on execution, would you be able to provide some insight on how to do this please? I'm not sure whether my issue is linked to [karate][standalone] Error : could not find or read file
Can you try the ZIP release and if you open the karate batch file you will see this:
java -cp karate.jar:. com.intuit.karate.Main $*
So the trick to setting a custom classpath is to use the com.intuit.karate.Main entry point and in the above example the current dir is also added to the classpath.
It would be great if you try the current RC version (0.9.5.RC3) to ensure we have everything working as expected.
For more information, see this part of the docs: https://github.com/intuit/karate/tree/develop/karate-netty#custom-classpath
I am running Spring 1.2.1.RELEASE with Liquibase in IntelliJ 14:
build.grade
compile("org.springframework.boot:spring-boot-starter-web:$springBootVersion")
compile('org.liquibase:liquibase-core')
I have a project/config/application.properties that I use to tell Liquibase to create the database and insert data:
spring.jpa.hibernate.ddl-auto=none
spring.datasource.url=jdbc:postgresql://localhost:5432/mydb
spring.datasource.username=xxx
spring.datasource.password=xxx
spring.datasource.driverClassName=org.postgresql.Driver
spring.jpa.database=POSTGRESQL
spring.jpa.hibernate.hbm2ddl.auto=none
spring.jpa.hibernate.disableConnectionTracking=true
spring.jpa.hibernate.default_schema=xxx
liquibase.change-log:classpath:/db/changelog/db.changelog-master.xml
liquibase.check-change-log-location=true
If I run from the command line:
gradle clean build
I will get all my tables and seed data in my database as expected. But if I run my main SpringBoot Application class from within IntelliJ no tables are created. I have a logging file that shows liquibase being used from the command line, but when I run from within IntelliJ, there is not mention of Liquibase in that log file. Just to be sure, I have a duplicate application.properites under project/src/resources.
Here is how my project looks i IntelliJ:
Any ideas on how to get the properties file used from within IntelliJ?
I want to prevent maven from displaying INFO messages, I want to see only WARNINGS and ERRORS (if any).
How can I achieve this, preferably by changing the command line that calls maven?
Answering your question
I made a small investigation because I am also interested in the solution.
Maven command line verbosity options
According to http://books.sonatype.com/mvnref-book/reference/running-sect-options.html#running-sect-verbose-option
-e for error
-X for debug
-q for only error
Maven logging config file
Currently maven 3.1.x uses SLF4J to log to the System.out .
You can modify the logging settings at the file:
${MAVEN_HOME}/conf/logging/simplelogger.properties
According to the page : http://maven.apache.org/maven-logging.html
Command line setup
I think you should be able to setup the default Log level of the simple logger via a command line parameter, like this:
$ mvn clean package -Dorg.slf4j.simpleLogger.defaultLogLevel=debug
But I could not get it to work. I guess the only problem with this is, maven picks up the default level from the config file on the classpath. I also tried a couple of other settings via System.properties, but all of them were unsuccessful.
Appendix
You can find the source of slf4j on github here : slf4j github
The source of the simplelogger here : slf4j/jcl-over-slf4j/src/main/java/org/apache/commons/logging/impl/SimpleLog.java
The plexus loader loads the simplelogger.properties.
Edit: this answer was from 2013, there are probably better ways to do this now, please consider the other answers.
Linux:
mvn validate clean install | egrep -v "(^\[INFO\])"
or
mvn validate clean install | egrep -v "(^\[INFO\]|^\[DEBUG\])"
Windows:
mvn validate clean install | findstr /V /R "^\[INFO\] ^\[DEBUG\]"
You can achieve this with MAVEN_OPTS, for example
MAVEN_OPTS=-Dorg.slf4j.simpleLogger.defaultLogLevel=warn mvn clean
Rather than putting the system property directly on the command line. (At least for maven 3.3.1.)
Consider using ~/.mavenrc for setting MAVEN_OPTS if you would like logging changed for your login across all maven invocations.
If you are using Logback, just put this logback-test.xml file into src/test/resources directory:
<configuration>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<root level="INFO">
<appender-ref ref="STDOUT" />
</root>
</configuration>
you can achieve this by using below in the commandline itself
-e for error
-X for debug
-q for only error
e.g :
mvn test -X -DsomeProperties='SomeValue' [For Debug level Logs]
mvn test -e -DsomeProperties='SomeValue' [For Error level Logs]
mvn test -q -DsomeProperties='SomeValue' [For Only Error Logs]
The simplest way is to upgrade to Maven 3.3.1 or higher to take advantage of the ${maven.projectBasedir}/.mvn/jvm.config support.
Then you can use any options from Maven's SL4FJ's SimpleLogger support to configure all loggers or particular loggers. For example, here is a how to make all warning at warn level, except for a the PMD which is configured to log at error:
cat .mvn/jvm.config
-Dorg.slf4j.simpleLogger.defaultLogLevel=warn -Dorg.slf4j.simpleLogger.log.net.sourceforge.pmd=error
See here for more details on logging with Maven.
Unfortunately, even with maven 3 the only way to do that is to patch source code.
Here is short instruction how to do that.
Clone or fork Maven 3 repo: "git clone https://github.com/apache/maven-3.git"
Edit org.apache.maven.cli.MavenCli#logging, and change
cliRequest.request.setLoggingLevel( MavenExecutionRequest.LOGGING_LEVEL_INFO );
to
cliRequest.request.setLoggingLevel( MavenExecutionRequest.LOGGING_LEVEL_WARN );
In current snapshot version it's at line 270
Then just run "mvn install", your new maven distro will be located in "apache-maven\target\" folder
See this diff for the reference: https://github.com/ushkinaz/maven-3/commit/cc079aa75ca8c82658c7ff53f18c6caaa32d2131
Go to simplelogger.properties in ${MAVEN_HOME}/conf/logging/ and set the following properties:
org.slf4j.simpleLogger.defaultLogLevel=warn
org.slf4j.simpleLogger.log.Sisu=warn
org.slf4j.simpleLogger.warnLevelString=warn
And beware: warn, not warning
In Debian this worked for me like a charm to change the log level for Maven 3.6 at runtime without having to change the simplelogger.properties file:
MAVEN_OPTS='-Dorg.slf4j.simpleLogger.defaultLogLevel=error' mvn test
I have noticed when using the 2.20.1 version of the maven sunfire plugin, all warnings are written down to a dumpstream file. e.g. /myproject/target/surefire-reports/2017-11-11T23-02-19_850.dumpstream
Changing the info to error in simplelogging.properties file will help in achieving your requirement.
Just change the value of the below line
org.slf4j.simpleLogger.defaultLogLevel=info
to
org.slf4j.simpleLogger.defaultLogLevel=error