Ответ 1
Это старая открытая проблема, связанная с мультимодульными проектами maven: http://jira.codehaus.org/browse/MCOMPILER-165
Я работаю над довольно большим проектом Maven и разрабатываю на Java с Eclipse.
Чтобы сохранить время компиляции, я хотел бы, чтобы Maven и Eclipse делились та же самая цель, которую мне удалось сделать. Однако, когда я компилирую Maven, Eclipse не хватает некоторых вещей, которые он вкладывает в байт-код, поэтому он перекомпилирует все (из того, что я понимаю). Я говорю о функции "build automatically" здесь, поэтому не Eclipse делегирует сборку Maven.
Чтобы решить эту проблему, я подумал, что попрошу Maven использовать тот же компилятор, что и Eclipse.
После некоторого поиска в Интернете я узнал, что могу добавить это в начало pom
:
<build>
...
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerId>eclipse</compilerId>
<source>1.5</source>
<target>1.5</target>
<optimize>true</optimize>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.plexus</groupId>
<artifactId>plexus-compiler-eclipse</artifactId>
<version>1.8.1</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
Это похоже на работу, но сборка происходит довольно быстро с большим количеством ошибки, в то время как он успешно работает с javac. Я не уверен, почему, но кажется, что есть некоторые конфликты, связанные с факт, что файлы с ошибкой Java являются сгенерированными файлами.
Итак, я думал, что могу попытаться использовать компилятор Eclipse только для
компонент, над которым я работаю (который не имеет такого сгенерированного
файлы). Я добавил фрагмент выше в pom
моего компонента, но когда
сборка достигает моего компонента, возникает следующая ошибка:
Нет такого компилятора 'eclipse'
Я также попытался добавить зависимость plexus-compiler-eclipse
в
зависимостей, перечисленных в верхней точке, но той же ошибки.
Вы знаете, возможно ли то, что я пытаюсь сделать? Любой намек на то, как я могу это сделать?
Это старая открытая проблема, связанная с мультимодульными проектами maven: http://jira.codehaus.org/browse/MCOMPILER-165
Я бы предположил, что ваши проблемы возникают из проекта eclipse, а maven pom не синхронизируется. Я бы предположил, что вы используете плагин m2eclipse, чтобы синхронизировать maven и eclipse. Это позволит настроить проект eclipse, используя POM в качестве "основной" конфигурации.
Я не думаю, что вам нужно конкретно настроить, какой компилятор использовать, но вы должны настроить maven-компилятор-плагин, как вы уже делаете.
Убедитесь, что вы используете последнюю версию maven-compiler-plugin
(2.3.2 прямо сейчас, см. эту страницу - это "Полное имя" или небольшую информацию о версии в верхнем правом углу).
Кроме того, конфигурация должна работать. Вы можете попробовать с последней версией версии 1.8.4 plexus-compiler-eclipse
.
Кроме того, вам нужно понять, что Maven имеет несколько типов зависимостей. В вашем случае интересны два: зависимости времени сборки и плагинов.
Первые собраны в элементе dependencies
, а последний должен находиться в pluginManagement
. Добавление плагина к пути времени сборки не будет иметь нужного эффекта.
Я не уверен на 100%, чего вы пытаетесь достичь здесь, но это звучит как плохая идея. Во-первых, вы должны настроить Eclipse на использование SDK в вашей системе, и Maven должен использовать одно и то же. Поэтому я не понимаю, почему вы думаете, что Eclipse добавляет что-то к байтовому коду, который Maven не получит, они оба используют один и тот же компилятор.
Во-вторых, я бы не пытался использовать какие-либо компоненты Eclipse в сборке maven. Они предназначены для работы в среде Eclipse IDE, поэтому заставить их работать вне этого, как правило, чреваты проблемами. Я видел, как это было сделано, но это был взлом и не принес очень хорошие результаты.
Чрезмерно, если у вас проблемы с производительностью с сборкой Maven (не редкость), есть несколько вещей, которые вы можете сделать. Во-первых, сломайте сборку и выясните, куда идет время. Мой опыт заключается в том, что обычно это не компиляция, которая является проблемой. Здесь список вещей, которые я видел, замедляет сборки:
Плохие тесты качества. Обычно медленный запуск тестов интеграции дополняется тестами, которые на самом деле являются модульными тестами, выполняемыми как интеграция.
Cobertura. Отличный инструмент, но из-за того, как работает Maven, плагин Cobertura должен снова запустить все этапы от ресурсов до компиляции. Я когда-то сбрил 40% во время длинной сборки Maven, написав плагин, чтобы остановить тесты, пока они не будут выполняться фазой cobertura.
Над зданием. то есть. включая подмодули, которые в принципе никогда не меняются. Лучший выбор - создать профиль, который включает эти подмаски только тогда, когда это необходимо, или разбить его на совершенно отдельную сборку.
Длительное тестирование интеграции. Если тесты интеграции занимают много времени, подумайте о том, чтобы включить их в другой профиль и другую сборку на сервере CI. Тогда ваша основная сборка может ускориться, что позволит разработчикам быстрее вернуться к работе, в то время как тесты интеграции могут выполняться реже.
Наконец-то признаем, что Maven - борец с производительностью и быстрее переходит к чему-то. Ant, вероятно, все же самый быстрый, но боль в настройке, потому что вам нужно вручную настроить все. Я предлагаю пробный Grandle, поскольку он исправляет множество проблем, которые имеют как Ant, так и Maven. Хотя, честно говоря, я лично не проводил никаких тестов производительности. Но это дает вам уровень контроля, которого нет у Maven.