Grails 3.2.0 Bootstrap.groovy скрипт не выполняется

#grails #grails3.2.0

#grails #grails3.2.0

Вопрос:

После того, как я обновил свой проект с Grails 3.1.11 на 3.2.0, проект перестал работать.

Когда я запускаю proj из IDE, он работает нормально. Но когда я упаковываю его в jar и пытаюсь запустить в терминале, BootStrap.groovy не выполняется.

В чем проблема?

Комментарии:

1. Ваш BootStrap.groovy находится в определенном пакете или только в пакете по умолчанию, например, в файле не определен пакет?

2. @GregorPetrin по умолчанию, пакета нет

3. Неважно, я только что протестировал, и он выполняется независимо, у нас возникли проблемы, например, с taglibs, для которых не определен пакет; ваш BootStrap в grails-app/init/BootStrap.groovy или где-то еще?

4. @GregorPetrin мой BootStrap.groovy находится в grails-app / init. Я уже нашел на GitHub вопрос об этой проблеме и ответил на него ниже. Спасибо за помощь!

Ответ №1:

Я только что обнаружил проблему на GitHub. Теперь BootStrap.groovy и UrlMappings.groovy должны быть в пакете по умолчанию

Пакет по умолчанию указан в application.yml

 grails:
    codegen:
        defaultPackage: com.example.app
  

В документах по миграции пока нет информации об этой проблеме..

Комментарии:

1. Добавлен запрос на извлечение в документацию: github.com/grails/grails-doc/pull/517

2. @GregorPetrin спасибо!

Ответ №2:

ответ Сергея Линника верен: файл Bootstrap.groovy должен находиться в пакете по умолчанию, но при использовании IDE (в моем случае Intellij 2016.2.4) обратите внимание на рефакторинг класса Bootstrap.groovy из папки init в добавляемый им пакет по умолчанию……. . . . . . ….. «инициализация»

 package default //ensure the package folder is added

class BootStrap {///}
  

В противном случае при сборке приложения grails файл Bootstrap.groovy снова перемещается из пакета по умолчанию, поскольку рефакторинг не обновил его. Не уверен, ошибка intellij это или нет..

Комментарии:

1. Я думаю, проблема здесь в том, что не имеет значения, где находится файл .groovy, файл .class будет размещен везде, где указано в объявлении пакета, поэтому, когда происходит импорт класса, им нужно искать его там, где указано в объявлении пакета, где он должен быть.