Allow to use paths relative to flyway.conf location

[alexei-osipov]

Right now locations defined in flyway.properties 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 flyway.properties to run some set of migrations.

Example file structure:
/someproject/migrations/flyway.properties
/someproject/migrations/sql/V1__aaa.sql
/someproject/migrations/sql/V2__bbb.sql
/someproject/pom.mxl
/tools/flyway/flyway.cmd

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 flyway.properties 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 flyway.properties (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
flyway.locations=filesystem:sql
and use flyway.properties file both from maven plug-in and command line tool.

[axelfontaine]

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.

[punkstarman]

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.

[punkstarman]

I have successfully used the following wrapper scripts:

Unix

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

# resolve links - $0 may be a softlink
PRG="$0"

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

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

# Use JAVA_HOME if it is set
if [ -z "$JAVA_HOME" ]; then
 JAVA_CMD=java
else
 JAVA_CMD=$JAVA_HOME/bin/java
fi

CP="$INSTALLDIR/lib/*:$INSTALLDIR/drivers/*"

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

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

# Save the exit code
JAVA_EXIT_CODE=$?

# Exit using the same code returned from Java
exit $JAVA_EXIT_CODE

Windows

@Echo off

setlocal

@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
set JAVA_EXIT_CODE=%ERRORLEVEL%

@REM Exit using the same code returned from Java
EXIT /B %JAVA_EXIT_CODE%

[RichardJECooke]

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

[hotzen]

+1 as well

[zetzet]

++: relative paths would be super helpful

[jedvardsson]

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.

[miro-ur]

+1, relative paths would be super

[r0mdau]

+1

[JDFagan]

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

flyway.locations=./sql/

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).

--
Update:

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

flyway.locations=filesystem:./sql/

[axelfontaine]

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

[lbreuss]

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

• http://www.mojohaus.org/exec-maven-plugin/exec-mojo.html#workingDirectory
• http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#workingDirectory

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.

[axelfontaine]

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

[lbreuss]

Agree. #1877