Вопросы Теги

Генерация источников путем выполнения класса Java проекта в Знатоке

Я преобразовываю великоватую сборку Муравья в Знатока. Как часть сборки Муравья, у нас есть несколько шагов, которые создали классы Java путем вызова одного из классов проекта, упрощенных как:

javac SomeGenerator.java
java  SomeGenerator  generated # generate classes in generated/
javac generated/*.java

Я разделил каждый генератор в его собственном модуле Знатока, но у меня есть проблема неспособности выполнить генератор, так как это еще не компилируется в generate-sources фаза.

Я попробовал что-то подобное

        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>exec-maven-plugin</artifactId>
            <version>1.1.1</version>
            <executions>
                <execution>
                    <id>generate-model</id>
                    <goals>
                        <goal>java</goal>
                    </goals>
                    <phase>generate-sources</phase>

                    <configuration>
                        <mainClass>DTOGenerator</mainClass>
                        <arguments>
                            <argument>${model.generated.dir}</argument>
                        </arguments>
                    </configuration>
                </execution>
            </executions>
        </plugin>

Который печально не работает по причинам, обрисованным в общих чертах выше. Разделяя генераторы кода на два проекта каждый, один для компиляции генератора и другой для генерации DTOs кажется излишеством.

Что альтернативы там?

Использование знатока 2.2.1.

11
задан Robert Munteanu 27 January 2010 в 13:35
поделиться

2 ответа

Вы можете выполнить Maven-Compile-Plugin в этапе генерации-источников. Просто добавьте еще одно исполнение перед существующим выполнением и настройте его, чтобы он просто поднимал источники для генератора.

Или разделить проект в два: построить генератор отдельным POM и включите библиотеку генератора в качестве зависимости от POM, который генерирует источники.

Лично я разделил проект. Удерживает очиститель файлов сборки и легче поддерживать.

8
ответ дан 3 December 2019 в 08:55
поделиться

Нет прямого способа сделать это.

Вы можете загрузить сценарий по запросу. (снова использует нечто похожее на то, что упомянул Игнасио, но намного чище).

Проверьте эту ссылку на наличие нескольких способов: http://ajaxpatterns.org/On-Demand_Javascript

Мой любимый вариант (не всегда применим): 

<script src="dojo.js" type="text/javascript">
dojo.require("dojo.aDojoPackage");

Закрытие Google также обеспечивает аналогичную функциональность.

-121--801980-

У меня недостаточно контекста, чтобы дать правильный ответ, но я предложу вам максимально сделать код неизменным . Используйте поля public final . Больше не получает или setters : каждое поле должно быть определено конструктором . Ваш код короче, удобочитаем и не позволяет писать код с побочными эффектами.

Это не мешает передавать пустые аргументы конструктору, хотя... Вы по-прежнему можете проверить каждый аргумент в соответствии с предложением @ cletus, но я предложу вам бросить IllegalArgumentException вместо StartPointerException , который не дает нового намека на то, что вы сделали.

В любом случае, это то, что я делаю как можно больше, и это значительно улучшило мой код (читаемость, стабильность). Все в моей команде так и делают, и мы этим очень довольны. Мы узнали, что когда мы пытаемся написать какой-то erlang код, где все незыблемо.

Надеюсь, это поможет.

-121--148â2-

Мы столкнулись с той же проблемой. Мы хотели уважать поведение Maven как можно ближе, не иметь проблем с плагинами и так далее... Сражаться с Мэйвеном слишком дорого!

Мы поняли, что частота обновления генерируемого кода обычно сильно отличается от частоты кода, который мы записываем вручную, поэтому разделение кода имело очень хорошие характеристики производительности для сборки. Поэтому мы решили, что наши сгенерированные классы являются зависимостью от написанного вручную.

Мы приняли следующую структуру, которая имела только одно небольшое изменение от обычной конфигурации maven, изменение в исходном каталоге.

Родительский проект: Поколения

Мы создали родительский проект для всех наших поколений .

  • Он имеет тип JAR, если он содержит код для компиляции, в противном случае POM.
  • Там мы имеем наш генерирующий код, in/src.
  • Он может компилировать в/target как обычно.
  • Выполняется генерация, каждый генератор создает код в подкаталоге/target.

Примечание. Если требуется несколько сгенерированных результатов в одной банке, просто поместите их в одну подкаталогу.

Дочерние проекты банок: Generateds

  • Является подкаталогом проекта Generations.
  • Имеет тип JAR.

  • Исходный каталог указывает на поддиректорию в родительском целевом объекте.

    < sourceDirectory > ../target/generated1

  • Он обычно компилируется в собственном/целевом каталоге.

Эта структура позволяет:

  • иметь как можно меньше изменений в стандартной макете maven,так что каждый maven команда и плагин продолжает работать хорошо.
  • мило, если у вас есть несколько генераторов,
  • мило, если вы хотите генерировать несколько банок (у нас был случай wsdl2java, где один генератор производил код, который должен быть разделен на несколько банок; каждый дочерний созданный проект будет иметь один и тот же исходный каталог, но будет сконфигурирован с < includes > для обработки только некоторых классов).
1
ответ дан 3 December 2019 в 08:55
поделиться
Другие вопросы по тегам:

Похожие вопросы: