spring run --local does not accumulate dependencies in a local directory #99
Assignees
Comments
|
I suspect I may have inadvertently broken this when I implemented the custom Aether-based Grape engine. I'll investigate. |
ghost
assigned
|
M5 pre-dates the Aether changes. The problem's due to the introduction of TestCommand. Its instantiation triggers GrapeIvy's one-off initialization and this is occurring before RunCommand has had a chance to set the system property that's used to configure the grape directory. This causes the default ( |
|
Then that would be my fault. Though I'm not sure if I grok what's happening. Have to read more code. |
gigfork
pushed a commit
to boostrack/spring-boot
that referenced
this issue
Apr 21, 2014
When running an application, --local can be used to collect the application's dependencies in a local directory. Prior to AetherGrapeEngine being introduced, using --local would result in the dependencies being written to ./grapes. When AetherGrapeEngine was introduced --local no longer had any effect. This commit updates AetherGrapeEngine so that it honours --local, writing its dependencies to ./repository. When --local is not specified dependencies are written to ~/.m2/repository (the standard location for the local Maven cache). As part of this change TestCommand has been refactored so that it lazily initialises its GroovyCompiler. This ensures that RunCommand has a chance to set the system property that backs --local before AetherGrapeEngine is initialised and accesses the property. Fixes spring-projects#99
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In Spring Boot 0.5.0.M5 (from the homebrew tap), the
--localoption no longer accumulates grapes in the$PWD/.grapesfolder. It would appear that the dependencies are being accumulated in their default location of$HOME/.gradle/grapes. To reproduce this issue simply run the 'quick start sample' with--local.The text was updated successfully, but these errors were encountered: