5

Here is my situation. I have a play app which uses the guice module. In order to work with the guice module:

  • I installed it using play install guice. This installs it in the $PLAY_HOME/modules which is fine by me. I don't want to edit the module files in any way whatsoever.
  • Then I declared the module in my dependencies.yml like so: - play -> guice 1.2
  • Within my app, I ran play dependencies, and this resoles the module just fine and creates a modules/guice-1.2 file that references the guice module.

The issue is that the content of that file is something like the following: /some-absolute-path/play-1.2.x/modules/guice-1.2.

That works fine when working locally for development. But when I want to move to a production server, with a different install of Play! (i.e. with a different absolute path to it) it will obviously fail.

So what's the best way to deal with this?

For now I've resorted to declaring the module in the application.conf file like this: module.guice=${play.path}/modules/guice-1.2. Unfortunately the ${play.path} magic doesn't seem to work on those generated files.

By the way I use version 1.2.3 of Play!

Pere Villega
  • 16,429
  • 5
  • 63
  • 100
SaM
  • 2,410
  • 1
  • 19
  • 19

3 Answers3

2

you should try with ${application.path} in your dependencies.yml file, like in this example

require:
    - play -> crud
    - provided -> DateHelper 1.0 
repositories: 
    - provided: 
        type:       local 
        artifact:   "${application.path}/jar/[module]-[revision].jar" 
        contains: 
            - provided -> *

see this question: How can I specify a local jar file as a dependency in Play! Framework 1.x

Community
  • 1
  • 1
opensas
  • 60,462
  • 79
  • 252
  • 386
  • 1
    Well this is not quite what I'm trying to achieve. The module I installed is installed in the `PLAY_HOME/modules` and I intend to use from there, since this is where play installs it. The dependencies.yml file also creates a local reference to it and doesn't copy it, so it comforts me in the fact that it shouldn't be copied across. I just want that reference to not be an absolute path but a relative (or parameterised) path to the module within the `PLAY_HOME/modules` directory. Does it make sense? – SaM Sep 05 '11 at 06:56
0

It's not answer to your question, but I have faced with same issue.

  • I don't want to call resync the dependencies on production.
  • I don't want to ask my team members, install special module.
  • I don't want to commit file containing absolute path with module location.

The only workaround that I find: do not install module in Play! application, just include jars which use this module manually. play-guice.jar should be included as @opensas suggested, aopalliance and com.google.inject as regular dependencies in dependencies.yml.

The funny thing, that resync dependencies is also deleting .svn files, so back-up its before calling this command.

Anton
  • 5,831
  • 3
  • 35
  • 45
0

When you run in production you will either resync the dependencies (via play deps command) with the local installation of Play or in some scenarios you can precompile everything and then there will be no issues with the paths.

That second scenario is the one with Heroku, for example.

Pere Villega
  • 16,429
  • 5
  • 63
  • 100
  • That sounds less than ideal. It looks like everything in Play! is made such as one doesn't have to change anything once files have been committed and simply use `pay start` in production. Re-running `play dependencies` in production seems counter productive, especially that it would change _source_ code in that case (i.e. the `module/guice-1.2`) file. I'm not entirely sure what you mean by the _precompile everything_ scenario. If I set my `application.mode` to `prod` then Play! does percompile. That doesn't change my problem here though… – SaM Sep 02 '11 at 12:25
  • @SaM well, on the absolute path, the only way to avoid it would be to have the same path in dev and prod, if nto you have to rerun the deps commands to avoid the issue. On precompilation, I just mentioned it because trying heroku I see it does that (maybe it's packing the code to a war? can't check now) and I had no problems with dependencies. So that could be the answer. – Pere Villega Sep 02 '11 at 12:45