Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow to use paths relative to flyway.conf location #944

alexei-osipov opened this issue Jan 28, 2015 · 14 comments

Allow to use paths relative to flyway.conf location #944

alexei-osipov opened this issue Jan 28, 2015 · 14 comments


Copy link

Right now locations defined in are relative to current working directory. This may be a command line tool location or location of pom.xml for Maven plug-in. This makes it very difficult to use single to run some set of migrations.

Example file structure:

Right now if I want to run migrations from maven plug-in with option configFile I have to set flyway.locations to migrations/sql in it. If I want to use same from command line tool I have to explicitly override locations with absolute path to sql file folder.

So I suggest to add a boolean option locationsAreRelativeToConfig. If it set to true then location of (or another file provided by configFile option) should be used as base directory for locations. So for example above it will be possible to set
and use file both from maven plug-in and command line tool.

Copy link

Thanks for the suggestion. I am not a fan of adding a config property for this. However... This behavior is currently unspecified. We could therefore specify it to be relative to either the current directory or, like you suggest, the directory the config was loaded from.

I'll need to put some thought into this as the what the implications are exactly.

In your case you can of course also simply put the location need for the command-line tool in the config file and override with the plugin config in the pom. All other proper can stay as is.

Copy link

I think that execution from the command line should resolve non-classpath relative paths by using the working directory (not the install directory), and the build tool should use the project root.
I believe that this behaviour is in line with most command line and build tools.
The change would only affect the wrapper scripts.

Copy link

I have successfully used the following wrapper scripts:


case "`uname`" in
  CYGWIN*) cygwin=true;;

# resolve links - $0 may be a softlink

while [ -h "$PRG" ] ; do
  ls=`ls -ld "$PRG"`
  link=`expr "$ls" : '.*-> \(.*\)$'`
  if expr "$link" : '/.*' > /dev/null; then
    PRG=`dirname "$PRG"`/"$link"

# Set the current directory to the installation directory
INSTALLDIR=`dirname "$PRG"`

# Use JAVA_HOME if it is set
if [ -z "$JAVA_HOME" ]; then


if $cygwin; then
  CP=$(cygpath -pw "$CP")

"$JAVA_CMD" -cp "$CP" org.flywaydb.commandline.Main $@

# Save the exit code

# Exit using the same code returned from Java


@Echo off


@REM Use JAVA_HOME if it is set
if "%JAVA_HOME%"=="" (
 set JAVA_CMD=java
) else (
 set JAVA_CMD="%JAVA_HOME%\bin\java.exe"

%JAVA_CMD% -cp "%~dp0\lib\*;%~dp0\drivers\*" org.flywaydb.commandline.Main %*

@REM Save the exit code

@REM Exit using the same code returned from Java

Copy link

+1 for relative paths. First thing I'm Googling as a brand new user.

Copy link

hotzen commented May 10, 2016

+1 as well

Copy link

zetzet commented Jun 15, 2016

++: relative paths would be super helpful

Copy link

jedvardsson commented Jun 22, 2016

Yes, I agree that it would be helpful to have some way to make references relative to the configuration file itself. I suggest looking at e.g. TypeScript and how it uses ./to denote that the referenced module is located relative to the referencing file. Thus file:myconfigs can still mean relative to the working dir and file:./myconfigs can mean relative to the config file.

Alternately, we could use a variables like $workdir and $confdir to be even more explicit.

@axelfontaine axelfontaine added this to the Flyway 4.1 milestone Jun 22, 2016
Copy link

miro-ur commented Oct 4, 2016

+1, relative paths would be super

Copy link

r0mdau commented Jan 3, 2017


@axelfontaine axelfontaine modified the milestones: Flyway 5.0, Flyway 4.1 Feb 7, 2017
Copy link

JDFagan commented Mar 6, 2017

This also should apply to flyway.conf (not just as well, I want to simply define this:


So that flyway can pickup my sql from Git repo in repo sub-directory where . represents current directory of my project root (i.e., my git repo directory).


My noob mistake. I got the above to work by changing above to:


@axelfontaine axelfontaine changed the title Allow to use paths relative to location Allow to use paths relative to flyway.conf location Nov 27, 2017
axelfontaine pushed a commit to flyway/ that referenced this issue Nov 27, 2017
Copy link

This has now been implemented for all client:

  • Command-line: relative to the current directory
  • Maven: relative to the pom.xml directory
  • Gradle: relative to the build.gradle directory

Copy link

lbreuss commented Dec 21, 2017

Regarding the maven plugin, other plugins provide a workingDirectory parameter.

For my schema unit tests, I would really like to use the original bundled /src/main/resources/util/flyway/conf/flyway_latest.conf, that references filesystem:../../database/. Now if during test phase I direct flyway-maven-plugin to use the config file at /target/util/flyway/conf/flyway_latest.conf, the relative path does not evaluate to /target/database/, but to /../../database/, which is an inexistent path and even outside the maven project. Currently, as a workaround, I have to use a filtered version of flyway_latest.conf.

Sorry to bring this 944 up again. I would have loved that the original posters desired behaviour would become the default: relative to the conf file.

I think in any case it would still be a good idea to allow the plugin to explicitely change to a workingDirectory.

Copy link

@lbreuss This is essentially a new feature request. Please file a new issue for that.

Copy link

lbreuss commented Dec 21, 2017

Agree. #1877

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests