Allow use of custom conf/ivysettings.xml file #21

wants to merge 4 commits into


None yet
3 participants

Added logic that searches for conf/ivysettings.xml in the repo, and if present installs it as the ivysettings.xml for the Play application. If the file is not present, proceeds with the Heroku-provided ivysettings.xml file.


naaman commented Aug 17, 2012

Thanks Charles. I think the approach we should take here is to look in $BUILD_DIR/.ivy2 for the settings rather than $BUILD_DIR/conf. Play! checks $HOME/.ivy2 for a settings file by default and the buildpack tells Play! to use ${BUILD_DIR} as the $HOME.

I thought about doing it that way, but I decided to go to a folder other than $BUILD_DIR/.ivy2/ivysettings.xml for a couple of reasons.

First, the logic on lines 52-54 that deletes any potential stale ivysettings.xml file is good, but if $BUILD_DIR is $HOME, then this will wipe the custom ivysettings.xml. Supporting custom ivysettings.xml files in this way gives up the certainty that last build's ivysettings.xml file has been destroyed and a new one is being used.

Second, I went with this location because using .ivy2/ivysettings.xml could lead to some confusion when bringing on newbies to the project.

Since Ivy expects to find $HOME/.ivy2/ivysettings.xml, a reasonable person who is new to ivy or Play might think that having $PROJECT_ROOT/.ivy/ivysettings.xml in place would be sufficient to build the project on a local development host, not realizing that the file must be copied to ~/.ivy2 before it will be recognized.

By putting the file in /conf, I was attempting to make it explicit that this is a Heroku-ism, and ensuring that a reasonable person would not think that simply having the ivysettings.xml file there in /conf would be sufficient to build the project locally without first copying the file to the proper location.

Finally, lots of default .gitignore files for Play, including the one here on github, will exclude .ivy2 out of the box.

However, I can see both sides of the argument. If you prefer, I will re-submit this pull request with the .ivy2/ivysettings.xml location instead of the conf/ivysettings.xml location. Let me know which way you'd like to go, and I can update the pull request accordingly.


naaman referenced this pull request in heroku/heroku-buildpack-java Aug 21, 2012


Allow setting of MAVEN_SETTINGS_URL in the env. #11


naaman commented Aug 21, 2012

@charlesjohnson We'd like to keep the heroku-specific stuff to a minimum so that this stuff is easy to deploy elsewhere (i.e. trying to avoid vendor lock-in). If you need any help with the logic for deleting stale settings, let me know.


jkutner commented Jan 2, 2015

I'm closing this in favor of #31

jkutner closed this Jan 2, 2015

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