К сожалению, Maven не слишком умён в многомодульных проектах. Стандартный проект PlayN (включая ваш) имеет следующую модульную структуру:
top
+- core
+- html (depends on core)
+- java (depends on core)
+- android, flash, etc.
Когда вы находитесь в каталоге top
и вызываете Maven, он считывает все POM подмодуля и «знает» обо всех из них и правильно настраивает classpath, чтобы они видели соответствующий каталог classes
, когда компилирование и запуск.
Но если вы зайдете, скажем, в каталог html
и вызовете Maven, он больше не будет "знать" обо всех подмодулях. Все, что он знает, - это html
POM, и когда он видит зависимость для чего-либо еще (например, модуля core
), он проходит стандартный процесс разрешения зависимостей, а именно:
- Проверьте локальный репозиторий Maven
~/.m2/repository
.
- Проверьте репозитории, явно указанные в POM.
- Проверьте Maven Central.
Когда у вас возникает ситуация, когда вы хотите запустить команду в одном из ваших проектов подмодулей, вы должны договориться сделать это из проекта верхнего уровня. Вот почему тестирование из командной строки включает запуск mvn test -P test-java
или mvn test -P test-html
из каталога верхнего уровня, а не просто запись в каталог java
или html
и запуск mvn test
.
К сожалению, уловки, которые мы используем, чтобы сделать возможным тестирование субмодуля Java или HTML из командной строки, не работают с gae:run
. Таким образом, в этом случае вы должны обойти ограничения Maven, сначала установив артефакты проекта в локальный репозиторий Maven, прежде чем вызывать gae:run
(и, на самом деле, делать это каждый раз, когда вы хотите протестировать с помощью gae:run
. Это выполняется примерно так :
cd top
mvn install
cd html
mvn gae:run
Было бы замечательно, если бы Maven был достаточно умен, чтобы обнаружить, что он запускается в каталоге подмодулей, и автоматически разрешать родственные зависимости таким же образом, как если бы вы вызывали Maven из каталога проекта верхнего уровня. Увы, умный - это прилагательное, которое редко применяется, когда речь идет о Maven.