И какое отношение ant имеет к IDE? Он от нее полностью независим. Попробуйте запустить его из командной строки в обоих проектах и смотрите где вы накосячили. У меня есть подозрения, что сборка проекта в netbeans является нечто большим, чем вызовом ant.

Если ваш make-файл не работает как надо, вы, наверно, линукс винить не будете, из которого вы его запустили.

PS Ant из JEdit у меня отлично работает. Может вы просто не поняли как им пользоваться? А codecomplit в jedit весьма ограниченный (собственно поскольку jedit это все-таки редактор текста, а не IDE, как Eclipse/NetBeans/Idea). Почитайте справку к плагинам, может на вас снизойдет просветление в каких случаях он работает.

+100!

сново про недосверх-программистов

[шутка удалась]
>недостаточно выразительная для высокоуровневых задач

видимо по этому на всякие выразительные языки никак толком не портируют Hibernate и Spring с "недостаточно выразительной" java.

И приходится писателям на этих чудо языках каждый раз со всей выразительностью изобретать колесо заново.

Bridgestone и Miсhelin в ужасе!

То ORM изобретут, то DI, то AOP, то unit testing framework,а то logging framework на коленке напишут... Ой, пардон муа, я же забыл.
Hibernte, Spring, AspectJ, JUnit и Log4j смогли портировать на более "выразительные языки" и теперь писатели изобретают на два/три новых колеса меньше...

Возможно Michlene не разорится, а вдумчивый читатель отметит, большинство успешных программных проектов делается на "недостаточно выразительной" java и только потом их пытаются портировать на бог весть какие "выразительные языки" (но не всем языкам везёт).

[А мужики то не знают!]
>при этом недостоточно производительная для расчётных и низкоуровневых

Некоторым это, как вы выражаетесь, достОточно.
Например Matlab интерпретатор написан на Java.
(если не целиком Matlab, пусть знатоки поправят).
Ох бедные бедные математики, они и не знали, что расчётные задачи делать на java - это недостОточно.
И я каюсь, грешен, ещё в университете переделывал систему распределённых вычислений с C++ на Java и она почему-то стала работать в полтора раза быстрее. Наверное это недостОточно быстро но людям из Дубны хватило.

[непереводимый фольклор]
>пруфлинк или не бывает.

я признаться не понял, что имел ввиду молодой патриот (как он сам себя называет), может кто переведёт, а другие посмеются?

Переводчика - патриоту!

Самого Пашу-патриота просить не будем, так как он слишком занят самовыражением на thread'e посвящённому профайлеру для языка, который он даже не пробовал учить занимаясь prolog'ом

[Горькая Правда]
>особенно GRASP порадовал

меня тоже, мне довелось править код за людьми на таких языках как C++,Haskell,PHP5,Perl и Java. так вот не умение применять GRASP (чаще всего Low Coupling и High Cohesion) было главной бедой программистов, работу которых мне приходилось переделывать(для Perl/Haskell LC/HC идет с поправкой на методы разумеется).

Как шутит один мой коллега - "Тяжело писать просто" (можно трактовать двояко).


[Горькая Правда 2 - судный день]
>во-первых неужели ты считаешь, что все, кто критикуют жабу этого всего не знают ?

На счёт все, это вы загнули. А вот всякие троли-патриоты не создавшие на java ни одного готового приложения или хотя бы библиотеки, которой пользуется пара тыс. человек, но все равно лезущие в форум посвяшённый java профайлеру, что-бы им там прилюдно показали их место, думаю толком не знают из этого списка ровным счётом ничего.


[сам с собой]
И почему это тролям-патриотам не общается с себе подобными?
Может им с умными людьми общается интересней?
Безусловно интересней - отвечает внутренний голос, гораздо интересней чем написать что-то хотя бы для OpenSource.
Можно даже статистику сделать - из ответивших наверняка будет преобладать число недосверх-программистов теоретиков только что изучивших новый язык идеально позволяющий программировать теоремы общей теории всего.

Вышеозначенная проблема скорее всего в /dev/hands и времени суток ;-)

у меня работают одни и те же проекты из под NetBeans/Eclipse/IDEA
сам предпочитаю Eclipse

но!!! что бы не иметь гемороя со сборкой - пользуйтесь Maven2


manual от maven - пустая трата времени
предворительно прочитайте вот эту книжку
http://repo.mergere.com/dist/maestro/1.5.1/BetterBuildsWithMaven.pdf

Удачи

> Hibernte, Spring, AspectJ, JUnit и Log4j смогли портировать на более "выразительные языки" и теперь писатели изобретают на два/три новых колеса меньше...

Уродская фигня получилась из портов junit и log4j на cpp. Фактически велосипед для логов для плюсов еще не найден (java-порты в топку).

>Некоторым это, как вы выражаетесь, достОточно.
>Например Matlab интерпретатор написан на Java.

в матлабе на жабе только гуй, а для расчётов там си и фортран... а ещё ядро мапла там тоже есть.

>>Некоторым это, как вы выражаетесь, достОточно.
>>Например Matlab интерпретатор написан на Java.

>в матлабе на жабе только гуй, а для расчётов там си и фортран... а ещё ядро мапла там тоже есть.

Google юзать не прет?

Integration with Java.
Matlab is tightly integrated with Java - the Matlab interpreter is written in Java. Can directly call Java code.

>startup ~160
>да, жаба очень быстра

и при этом поравала всех по всем отсальным тестам!

Писец, это правда или тесты лажа?

если правда - на жабе переписывть все кроме дров и скриптов?

Гы жаба захватывает мир!

>Уродская фигня получилась из портов junit и log4j на cpp

не гони, cppunit рулят и мне пох что их жабы сперли.

Yilativs - сцуко жжещь!!!
Пиши ещё!

>Уродская фигня получилась из портов junit

Гонишь!

ты на чем пишишь тесты, если пишешь вообще?

>Вышеозначенная проблема скорее всего в /dev/hands и времени суток ;-)

Проблема в Eclipse.

>у меня работают одни и те же проекты из под NetBeans/Eclipse/IDEA
сам предпочитаю Eclipse

Ну и что?

>но!!! что бы не иметь гемороя со сборкой - пользуйтесь Maven2

У меня не было геммороя со сборкой в Ant'е, а вот Eclipse конкретно затупила.

Чем же хорош Maven, если его скрипты такие многословные? (Вообще XML имеет оверхед, но в Maven оно превзошло лучшие ожидания).

>предворительно прочитайте вот эту книжку

Спасибо. Почитаю.

>Ну и что?

То, что если у тебя что-то не работает, попробуй сначала посмотреть в /dev/hands

>У меня не было геммороя со сборкой в Ant'е,

попробуй пособирать большие проекты с кучей зависимостей.

>Чем же хорош Maven,
Тем что умет отслеживать зависимости, и тем что на написание среднестатистического build файла ты потратишь в 10 раз меньше времени,
а на поддержку его другие люди потратять время в 100 раз меньше ;-)


>если его скрипты такие многословные?
заметно меньше чем аналогичные на ant.

остальное в книге

Удачи.

>>Чем же хорош Maven,
>Тем что умет отслеживать зависимости,

Этокаг? Глупости какие-то. Как-будто Ant не способен на это.

>и тем что на написание среднестатистического build файла ты потратишь в 10 раз меньше времени,

Не верю, Станиславский. Судя по книге, pom.xml куда навороченнее получается. И ещё куча подкаталогов набирается:
src/main/java
src/main/resources
src/main/resources/META-INF
src/test/java
src/test/resources

Зачем это фсё, если можно в проекте определить только нужные каталоги:
src
res
tst
META-INF

???


>а на поддержку его другие люди потратять время в 100 раз меньше ;-)

Что, на это так влияет увеличение количество каталогов и их уровней их вложенности? :)

я хренею дорогая редакция
по вашим ссылкам, java медленне С++ в 15-50 раз ....

>Этокаг? Глупости какие-то. Как-будто Ant не способен на это.

Разве что вместе с ivy, а так -- нет.

>Не верю, Станиславский. Судя по книге, pom.xml куда навороченнее получается. И ещё куча подкаталогов набирается:

Смотря что и как. Вообще, мавеновские POM-ы хорошо реюзаются с других проектов методом копи-паста :)

>Что, на это так влияет увеличение количество каталогов и их уровней их вложенности? :)

Главное то, что во всех адекватных Maven2-проектах они одинаковые и не надо тратить время, чтобы понять куда в очередной раз запихали сорцы к тестам, в src/tst, test или еще куда-нибудь.

>я хренею дорогая редакция >по вашим ссылкам, java медленне С++ в 15-50 раз ....

Вообще, по CPU худший результат -- в 2.6 раза медленнее (если не считать время старта).

ошибся

но тогда почему же она все-же тормозит ?

>Вообще, мавеновские POM-ы хорошо реюзаются с других проектов методом копи-паста :)

Можно подумать, что build.xml'и пишутся каждый раз заново и по-своему. :O
Таски Анта хорошо колекционируются в библиотеки.

>Главное то, что во всех адекватных Maven2-проектах они одинаковые

Ну раз приняли окончательное решение (унифицировали), что каталог с сорцами обзывается "src", а с ресурсами обзывается "resources", то это уже считается преимуществом?

> и не надо тратить время, чтобы понять куда в очередной раз запихали сорцы к тестам, в src/tst, test или еще куда-нибудь.

Да уж...

несмешная, однако, шутка. ну давай по порядку

>видимо по этому на всякие выразительные языки никак толком не портируют Hibernate и Spring с "недостаточно выразительной" java

а зачем их туда портировать если они уже написаны на Java ? есть такое понятие, как legacy-код. скажи, почему в таком случае ядро Linux никак на Java не перепишут, если она такая хорошая ?

>И приходится писателям на этих чудо языках каждый раз со всей выразительностью изобретать колесо заново

4.2. или для Java уже сделали, например, что-то аналогичное Mnesia ? Blitz++ ? CERNLib ? FFTW ? Gamess ?

>Bridgestone и Miсhelin в ужасе!

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

>большинство успешных программных проектов делается на "недостаточно выразительной" java и только потом их пытаются портировать на бог весть какие "выразительные языки" (но не всем языкам везёт)

а ну-ка ну-ка, список "успешных программных продуктов" в студию. ты правда считаешь что на C/C++ их меньше ? если да, то мне тебя жаль

>достОточно

придираться к опечаткам - прекрасный, просто замечательный стиль ведения дискуссии

>Например Matlab интерпретатор написан на Java

ну ошиблись люди, с кем не бывает

>[непереводимый фольклор]

перевожу : приведи хотя бы один пример, в котором противник Java здесь на ЛОРе говорил бы о том, что "на Java никто не пишет"

>ввиду молодой патриот (как он сам себя называет)

за переход на личности в техническом треде стоило бы отрывать три и более конечностей

>Самого Пашу-патриота просить не будем, так как он слишком занят самовыражением на thread'e посвящённому профайлеру для языка, который он даже не пробовал учить занимаясь prolog'ом

на SWI Prolog я писал очень давно и очень немного. если бы ты читал внимательней, то заметил бы, что Prolog был моим первым языком программирования. что касается того, что я пробовал учить и чего не пробовал - не тебе судить, Java-addicted ты наш

>[Горькая Правда]

ты прав, с правдой у тебя хреново получается

>C++,Haskell,PHP5,Perl и Java. так вот не умение применять GRASP

GRASP как паттерны - абсолютно бесполезны. а то, что ты называешь "Low Coupling и High Cohesion" относится прежде всего к грамотной процедурной/обьектной декомпозиции и навыкам абстракции

>На счёт все, это вы загнули

так "вы" или "Паша-патриот" ? ты определись уж как-нибудь, интересно же

>А вот всякие троли-патриоты не создавшие на java ни одного готового приложения или хотя бы библиотеки, которой пользуется пара тыс. человек, но все равно лезущие в форум посвяшённый java профайлеру, что-бы им там прилюдно показали их место, думаю толком не знают из этого списка ровным счётом ничего.

если ты не заметил, то я отвечал не топикстартеру, а тебе. касательно твоего комментария, касающегося ЛОРа и людей, критикующих Java. про профайлер я не сказал ни слова

приложения и бибилиотеки, которыми пользуется пара тысяч (и более) человек я создавал. это бессмысленная с точки зрения дискуссии информация, просто лично тебе как любителю переходить на личности - с десяток успешно выполненных проектов у меня за спиной есть. в массе своей это C, C++ и Tcl/Tk, хотя писал я и на C#. на Java я не писал по одной простой причине - жаба мне не нужна. если бы вместо брызганья слюной ты перечислил бы аргументы её применения в проекте - я бы тебя с интересом почитал

>что-бы им там прилюдно показали их место

троллишь в данном случае ты. не я начал этот тред, не я высказался по поводу "людей, критикующих java". начинаешь оскорблять окружающих - будь готов, что тебе кто-нибудь да ответит. или твой "непатриотичный" мозг этой простой мысли осилить не в состоянии ?

>[сам с собой] И почему это тролям-патриотам не общается с себе подобными?

тут ты всё верно написал - это именно к тебе вопрос :)

>Можно даже статистику сделать - из ответивших наверняка будет преобладать число недосверх-программистов теоретиков только что изучивших новый язык идеально позволяющий программировать теоремы общей теории всего

фантазировать ты можешь сколько угодно. поучись ещё аргументировать свою позицию. не переходить на личности. и думать - думать тоже иногда бывает полезно

>но тогда почему же она все-же тормозит ?

Sun Java не тормозит!

>У меня есть подозрения, что сборка проекта в netbeans является нечто большим, чем вызовом ant.

Это именно вызов, ant - только пути к библиотечкам (по сути - к окружению сборки) без нетбинса придется явно указать самим, например в отдельном ant файле:

<path id="commonsSSLLib"> <fileset dir="${env.JAVA_COMMON}/CommonsSSL" includes="*.jar"/> </path> <property name="libs.CommonsSSL.classpath" refid="commonsSSLLib"/>

более того, нетбинсу можно указать использовать не встроенный ant, а внешний (например, с уже установленными собственными расширениями)

в результате все проекты будут собираться без IDE, единственная проблема возникнет с веб проектами - им нужна какая-то либа из нетбинса, но ее можно и вытащить.

> не гони, cppunit рулят и мне пох что их жабы сперли.

cppunit не нужен. посмотри tut framework, плюсовый а не жабный подход. также и log4cpp/log4cxx/log4c++ - жабокод. Бэкпорты с явы на плюсы не гуд.

>но тогда почему же она все-же тормозит ?

Частично -- из-за памяти, наверное, потом эти 2.6 раза, а самая большая проблема, имхо, -- большое число идиотов, которые тянут в рот что ни попадя. Натащщут в приложение слоев 20 разных фреймворков и удивляются, что оно еще шевелится.

>Можно подумать, что build.xml'и пишутся каждый раз заново и по-своему. :O >Таски Анта хорошо колекционируются в библиотеки.

Вот пример POM-а: http://nanorm.googlecode.com/svn/trunk/pom.xml

Он позволяет мне делать следующие действия одной командой (из ежедневного, реально список зависит существующих плагинов плюс я мог забыть что-то):

1) Очищать дерево исходников 2) Собирать JAR-архив и JAR-архив с исходниками 3) Запускать Unit-тесты 4) Собирать артефакты и загружать их в репозиторий (JAR и JAR с исходниками), таким образом другие смогут им воспользоваться 5) Подготавливать релиз (включая теггирование) 6) Проверять, все ли лицензионные хидеры на месте и добавлять в те файлы, в которых они пропущены. Также это делается автоматически при сборке. 7) Генерировать различные отчеты: JavaDoc, PMD, JDepend, по Unit тестам, Changelog из SVN,список TODO и список зависимостей 8) Генерировать простенький сайт с лицензией, командой, ссылкой на SVN и багтрекер (остальное типа ссылки на мейл-листов и CI сервер просто не заполнено в POM), плюс отчеты из 7) 9) Анализировать зависимости (посмотреть транзитивные зависимости)

При этом все зависимости скачиваются автоматически, мне не нужно рыскать по проектным сайтам выискивая JAR-ки. Также, скачиваются и исходники зависимостей (если они присутствуют), что позволяет навигироваться по коду этих зависимостей.

А теперь покажи антовский скрипт с аналогичной функциональностью :)

Да, можно это все вынести в макросы/таски внутри своей компании. Но в "чужих" проектах все будет сделано по-другому. А я этот POM.xml тупо скопипастил из другого проекта :)

>Ну раз приняли окончательное решение (унифицировали), что каталог с сорцами обзывается "src", а с ресурсами обзывается "resources", то это уже считается преимуществом?

Вообще, да. В Maven2 главное не тул, а всё в целом :)

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

>Вот пример POM-а: http://nanorm.googlecode.com/svn/trunk/pom.xml

Представляет собой монолит. Глыба. В отличие от антовских тасков, это — нечто сильносвязное.
Да, такой файл руками не наберёшь. Либо наберёшь с ошибками. Осюда: зависимость от среды (неважно какой).

Фактически это — другой язык и другая семантика.

>А теперь покажи антовский скрипт с аналогичной функциональностью :)

Не буду. У меня многих аналогичных тасков нет (потому что они мне не необходимы). А то, что есть, весьма простое и обозримое (в build.xml всего 253 строки, в build.properties ~10 строк).

>Представляет собой монолит. Глыба. В отличие от антовских тасков,
это — нечто сильносвязное.

Наоборот, это независимые декларации разных аспектов проекта и плагинов.

>Да, такой файл руками не наберёшь. 

Вообще, я их руками набираю, в vim-е. Итеративно. На самом деле,
конкретно для сборки проекта достаточно было:

<?xml version="1.0" encoding="UTF-8"?>
<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.google.code.nanorm</groupId>
  <artifactId>nanorm</artifactId>
  <name>nanorm</name>
  <version>0.1.0-SNAPSHOT</version>
  <build>
      <plugin>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.5</source>
          <target>1.5</target>
          <debug>true</debug>
        </configuration>
      </plugin>
  </build>
  <dependencies>
    <dependency>
      <groupId>commons-lang</groupId>
      <artifactId>commons-lang</artifactId>
      <version>2.4</version>
    </dependency>
    <dependency>
      <groupId>org.apache.geronimo.specs</groupId>
      <artifactId>geronimo-jta_1.0.1B_spec</artifactId>
      <version>1.1.1</version>
      <scope>provided</scope>
    </dependency>
    <dependency>
      <groupId>asm</groupId>
      <artifactId>asm-all</artifactId>
      <version>3.1</version>
    </dependency>
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-api</artifactId>
      <version>1.5.2</version>
    </dependency>
    <dependency>
      <groupId>com.h2database</groupId>
      <artifactId>h2</artifactId>
      <version>1.0.72</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.4</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-log4j12</artifactId>
      <version>1.5.2</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

А это просто версия, имя, и зависимости. Плюс компилятор настроен
на Java 5. Ничего сложного. При этом основное место тратится из-за
того, что группа/артефакт/версия/область задаются элементами, а не
аттрибутами. Я бы предпочел <dependency groupId="org.slf4j"
artifactId="srf4j-api" version="1.5.2"/>

Всё остальное либо копипастится с какого-то подходящего проекта, либо
набирается после чтения документации на тот или иной плагин, либо
копипастится с этой же документации (ко всем внятным плагинам
приведены типовые примеры).

При этом опять же, у всех Maven2 проектов POM выглядит примерно так
же, плюс-минус.

>Либо наберёшь с ошибками. Осюда: зависимость от среды (неважно какой). 

Как раз наоборот. Я больше сторонник CLI, а IDE -- это для удобства
навигации по коду, рефакторинга, автокомплита. Сборку я пишу руками
в vim.


На самом деле, самая проблема Maven2 -- кривая обучения. Слишком
много gotchas, недоделок, непоняток. Принципиально нерешаемых задач
нет, но есть моменты, которые решаются неоптимально/криво.

Спасибо за разъяснения. Очень кстати.

Наблюдение такое
Во время работы Maven закачивает недостающие модули в репозиторий ~/.m2/repository/

Вопрос назрел
А если у заказчика не будет этого репозитория и не будет mvn вообще, то как распространять приложение в исходных текстах? С Ant'ом проблема решается раз и навсегда: просто указывается ссылка на Ant, заказчик скачивает его, устанавливает, собирает приложение в off-line без доступа в Интернет, и вопрос решён.

>Вообще, я их руками набираю, в vim-е. Итеративно. На самом деле, конкретно для сборки проекта достаточно было:

Ой, а чего это такой простой пример? Вы лучше приведите пример, что нужно сделать чтобы сформировать корняк собранного приложения с произвольной струкутурой каталогов и .bat/.sh для запуска и с формированием произвольной БД (чтобы можно было выполнять SQL запросы), которая потом в эту же структуру каталогов помещается, а потом еще и со сжатием всего этого дела в архив. Да, чуть не забыл - обработка конфигурационного файл каким-нибудь макропроцессором, чтобы можно было сразу собирать под конкретную целевую платформу. Сейчас это все замечательно делается ant'ом с расширениями и строк там всего около 1000 (включая текст DDL sql запросов). При этом нету не какой "декларативности" (обратите внимание на кавычки!) - есть четкая последовательность шагов, из которой все предельно ясно. А для управления зависимостями есть Ivy, который с прошлой осени переехал под крышу ant'а.

У мавена две проблемы:

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

2) слишком высокая сложность использования - инструмент для сборки не должен быть таким сложным

P.S. Вот если бы оставить ту же систему управления зависимостями, выкинуть нахрен жестко прописанный lifecycle (сделать произвольные target'ы как в анте) и сделать возможность писать (и вызывать) расширения также легко как в анте (и когда угодно!!!!!), написать нормальную документацию - вот тогда им стоило бы пользоваться. А иначе - я не готов тратить на борьбу со сборщиком время, сопоставимое с написанием самой программы.

>Вот если бы оставить ту же систему управления зависимостями, выкинуть нахрен жестко прописанный lifecycle (сделать произвольные target'ы как в анте) и сделать возможность писать (и вызывать) расширения также легко как в анте (и когда угодно!!!!!), написать нормальную документацию - вот тогда им стоило бы пользоваться. А иначе - я не готов тратить на борьбу со сборщиком время, сопоставимое с написанием самой программы.

Похоже на то.

Я сейчас переделываю проект J2ME для Maven'а. Нашёл j2me-plugin:
http://mojo.codehaus.org/j2me-maven-plugin/project-summary.html
Прописал в pom.xml и settings.xml всё, как здесь описано:
http://mojo.codehaus.org/j2me-maven-plugin/howto.html

Запускаю:
> cd /home/igor/projects/floresirisme
> mvn package -Dj2me.sdkPath=/usr/local/sun-wtk -Dj2me.midlet.name=SysInfoMIDlet 
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building floresirisme
[INFO]    task-segment: [package]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] The plugin 'org.codehaus.mojo:j2me-maven-plugin' does not exist or no valid version could be found
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 second
[INFO] Finished at: Sun Jul 13 02:43:12 MSD 2008
[INFO] Final Memory: 3M/6M
[INFO] ------------------------------------------------------------------------

Дальше не знаю, куда рыть...

>А если у заказчика не будет этого репозитория и не будет mvn вообще, то как распространять приложение в исходных текстах? С Ant'ом проблема решается раз и навсегда: просто указывается ссылка на Ant, заказчик скачивает его, устанавливает, собирает приложение в off-line без доступа в Интернет, и вопрос решён.

Без онлайна он нифига не соберет. Увы.

Разве что собрать всё, что нужно в репозиторий (включая куски мавена), запаковать его .zip-кой и подарить заказчику.

>Ой, а чего это такой простой пример? Вы лучше приведите пример, что нужно сделать чтобы сформировать корняк собранного приложения с произвольной струкутурой каталогов и .bat/.sh для запуска и с формированием произвольной БД (чтобы можно было выполнять SQL запросы), которая потом в эту же структуру каталогов помещается, а потом еще и со сжатием всего этого дела в архив.

В архив произвольной структуры я собираю assembly плагином. Соответственно, .bat/.sh кладу куда-нибудь в src/main/assets.

Про БД не понял мысли. Создать БД, заполнить её чем-нибудь и запаковать в архив? Биндишь на фазу package действия: создать БД, выполнить SQL скрипты, потом в assembly дескрипторе запаковываешь всё это.

>1) кривая в жопу документация из которой понятно как решилась конкретная проблема в примере, но вот когда потребуется сделать то же, но чуть-чуть по другому - выясняется что вот здесь можно сделать только так, а вот тут только эдак (и это считается стандартом).

Есть такое.

>2) слишком высокая сложность использования - инструмент для сборки не должен быть таким сложным

Возможно. Я как-то уже наловчился :)

>P.S. Вот если бы оставить ту же систему управления зависимостями, выкинуть нахрен жестко прописанный lifecycle (сделать произвольные target'ы как в анте)

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

>и сделать возможность писать (и вызывать) расширения также легко как в анте (и когда угодно!!!!!)

Расширения можно вызывать когда угодно, в рамках стандартного lifecycle.

Вот чего мне не хватает -- нельзя вызвать плагин с конфигурацией, заданной в POM.xml под заданным execution id. Это очень печально.

>Дальше не знаю, куда рыть...

А его просто нету в репозитории и всё :)

Открываешь в браузере http://repo1.maven.org/maven2/org/codehaus/mojo/, смотришь, там его нет. Тут http://snapshots.repository.codehaus.org/org/codehaus/mojo его тоже нет.

>>Дальше не знаю, куда рыть...

>А его просто нету в репозитории и всё :)

Ээээ... а как же web-страницы с описанием использования? Ж)
Выходит, что их нагенерил Maven просто так? Ж)

>Ээээ... а как же web-страницы с описанием использования? Ж) >Выходит, что их нагенерил Maven просто так? Ж)

Это два разных действия -- деплоймент сайта и самих артефактов :)

Можешь забрать исходники из SVN (на сайте должна быть ссылка), потом в исходниках mvn install сделать, оно соберет плагин и в локальный репо задеплоит. Но вообще, у меня такое ощущение, что на этот плагин вообще забили.

А что вы на это скажете:
http://javatalks.ru/ftopic4776.php
"Ситуация: проект разрабатывается уже год - билд делается мавеном. И вот однажды (на прошлой неделе) в ясный солнечный день паблик-репозиторий tanesha.net падает и... мы его 3 дня по кусочкам собираем из разных источников (публичные репозитории, локальные на машинах)... говорят мавен призван облегчить управление зависимостями. Может мотивация и была такой, но реализация далека от действительности. iText, например, в одних местах лежит как iText/iText, в других - lowagie/iText. Некоторые из версий в репозиториях не имеют pom-файлов. Кто во что горазд. Смена версии плагина - и вуаля - вчерашний успешный билд сегодня уже валится. Единственный способ хоть как-то стабилизировать повторяемость билдов и обеспечить повторяемость - пихать все либы в SVN/CVS... Но тут опять веселые "фичи" мавена - он гребет из инета их СТОЛЬКО, что места не напасешься. К слову из для обеспечения билда ear вместе со всеми либами размером в 9 Мб, мавен выгреб из инета либ на 50 Мб.
Итого... лишний раз убеждаюсь: хочешь сделать хорошо, делай сам, а потому не вижу конкуренции анту в лице мавена, ибо последний не удовлетворяет как-минимум трем основным требованиям к билд-системе:
- repetability (повторяемость)
- consistency (целостность)
- reliability (надежность)
ну и accessibility (доступность) вызывает серьезные вопросы."

По мне, так ситуация с Maven удручающа.