Здравствуйте, Mr.Delphist, Вы писали:

MD>>>Что значит "часть команды работает в другой IDE"?!
C>>То и значит. Удивительно, но только в Дельфе и заражённой её C# язык и IDE — это одно и то же.
MD>[off] Не ведитесь на ник — я ещё и асм с TCL знаю [/off]
А Smalltalk?

Здравствуйте, LeonidV, Вы писали:

LV>Глупость. Каждый выбирает тот инструмент, который ему удобней. Задача тех.лида (как руководителя) сделать так, чтобы его подчиненным было удобно. Единая система управления задачами, единая СУВ — это для удобства программиста. Но где ему конкретно работать (ОС) и на чем писать код (IDE), да даже какой профайлер использовать — это уже личное дело человека. Java как раз ценна тем, что в отличие от решений Apple/MS предоставляет свободу выбора программистам. maven (или подобная технология) — еще один кирпичик в фундамент этой свободы.

Как-то у меня то ли от не-джавного экспириенса, то ли от MS-козней, пока что статистика иная: все эти "светочи демократии", "непризнанные гении" и прочие альтернативные товарищи являются элементом из столь любимой на RSDN серии "не нужен".

Повторюсь: мне глубоко поровну, в чём у себя там товарищ пишет, на каком континенте находится и по какому графику работает. Мы команда, у нас общая цель, мы идём к ней. Но если коммиты этого человека являются регулярными головняками для команды, то вместо разборок "как починить" они будут откатываться. Потому что мы перестаем идти к цели. Потому что начинаем обслуживать гениальность одного (или нескольких) человека вместо интересов Заказчика.

Снова повторюсь: в проекте должны быть правила. Они не от хорошей жизни, не самые лучшие, но без них будет анархия. Обычно есть два и более способа сделать что-либо, но для целостности решения надо выбрать какой-то один в качестве стандарта, и чётко ему следовать. Товарищам несогласным могу порекомендовать попытаться закоммитить что-нибудь гениальное в тот же Spring или иной опен-сорц взрослого масштаба. Ой, Вас не пустили в транк? Ой, Вашу гениальность не оценили? Дурацкие там правила, оказывается, да? Наверное, и весь проект тоже дурацкий?
Отличие проекта на работе от опенсорсного проекта — у Вас есть куда более весомая возможность влиять на процесс. Аргументируйте, аргументируйте и еще раз аргументируйте своё предложение. Накапливайте статистику (только не будьте занудой) — и всё обязательно получится!

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, RomikT, Вы писали:

C>>>Казалось бы, достаточно зайти в каталог с модулем Б и запустить билд? Ан нет, фигушки. Сначала нужно зайти в модуль А, сделать там mvn install, и только потом зайти в модуль Б и там уже начать строить. Сам Maven ну никак не может догадаться, что этот модуль можно построить (он лежит локально рядом и доступен через родительский POM!!!).
RT>>Это была основная причина выбора Gradle — у меня ожидается довольно большое количество модулей (ибо OSGi).
RT>>С Maven действительно пришлось бы постоянно собирать всё, с Gradle такой проблемы нет. Он сначала соберёт все изменившиеся зависимости, а потому уже и текущий модуль.
C>Я пробовал, у меня не получилось — та же проблема, что и с Maven.
Попробовал ещё раз, всё работает:

C:\Workspaces\GradleTest\m2>gradle compileJava
:m1:compileJava
:m1:processResources
:m1:classes
:m1:jar
:m2:compileJava

C:\Workspaces\GradleTest\m2>gradle clean compileJava
:m2:clean
:m1:compileJava UP-TO-DATE
:m1:processResources UP-TO-DATE
:m1:classes UP-TO-DATE
:m1:jar UP-TO-DATE
:m2:compileJava

Архив проекта: http://files.rsdn.ru/35651/GradleTest.zip

C>>>Кстати, ещё не хватает out-of-tree билдов. Т.е. чтоб исходники можно было на read-only носителе, к примеру, иметь. Ну да ладно, можно прожить без этого.
RT>>В интернете пишут, что buildDirName=file('/tmp/myBuild') вполне работает. Сам не проверял.
C>В Maven'е теоретически тоже. На практике, результаты другие.
Проверил, действительно не работает
Точнее, buildDir переопределяется правильно, но в корневом проекте всё равно создаётся папка .gradle c какими-то кэшами.

On 18.04.2011 11:25, Mr.Delphist wrote:

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

"С вами невозможно спорить !" (с) Но остаётся неясной связь правильной
цели и стремление к тому, чтобы все пользовались одной и той же IDE (с
чего всё и началось).

--
WBR,
Serge.

Здравствуйте, Cyberax, Вы писали:

O>>Все эти проблемы легко решаются при помощи ключиков -pl -am -rf:
O>>http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-advanced-reactor-options/
C>Не помогает если надо запустить какой-то плугин, который есть только в этом модуле.

Можно подробнее про хитрый плугин?
Ключ -rf советуется консольным выводом мавена при любом фейле. Работает без проблем. Жаль, что идеевский плагин его не понимает.

Здравствуйте, Mr.Delphist, Вы писали:

MD>Лупить. Затем еще раз лупить. Вплоть до отстранений/увольнений для "особо продвинутых". Пока не дойдет, что в проекте должны единообразно соблюдаться вполне определенные вещи:
MD>

MD>
• кодинг-стайл
  MD>
• инструментарий
  MD>
• воркфлоу (багтрекер, сорс-контроль и всё такое)
  MD>

MD>Что значит "часть команды работает в другой IDE"?! Да хоть в Зимбабве едут и там на голове пускай стоят — но если их коммиты разламывают проект в дефолтной IDE проекта, они сами себе буратины.

И Фар, значится, нельзя, если у тимлида любимый файл-менеджер Тотал Коммандер?
Кодинг-стайл не зависит от выбранной IDE. И корректность коммита должна определяться не сборкой в дефолтной (опять же любимой тимлидом) IDE, а сборкой билд-сервера плюс ручным code review.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Mr.Delphist, Вы писали:

MD>>>>Что значит "часть команды работает в другой IDE"?!
C>>>То и значит. Удивительно, но только в Дельфе и заражённой её C# язык и IDE — это одно и то же.
MD>>[off] Не ведитесь на ник — я ещё и асм с TCL знаю [/off]
C>А Smalltalk?

Нет, лишь плюсы в какой-то мере умею

Здравствуйте, hrensgory, Вы писали:

H>"С вами невозможно спорить !" (с) Но остаётся неясной связь правильной
H>цели и стремление к тому, чтобы все пользовались одной и той же IDE (с
H>чего всё и началось).

При старте проекта утверждается дефолтный инструментарий, на котором должна быть обеспечена собираемость.
Грубый пример: если мы говорим, что базовым IDE проекта будет Visual Studio 6, то стройными рядами в лес отправятся как адепты свежайших VS20xx, так и гики Эклипса и командной строки, если их жизнедеятельность будет порождать подобные кейсы:

Кейс А:
— Вася, привет
— Привет
— Вась, тут беда с твоим коммитом — шестерка отказывается компилить файл, хотя внешне выглядит нормально
— А, понятно! Когда ж вы тоже на последнюю студию перейдёте — там юникод полностью поддерживается
— Перейдем, как Заказчик одобрит бюджет на лицензии. А пока — откатываем тебя, полностью.

Кейс Б:
— Коля
— Ась?
— Глянул твой вчерашний коммит. Там же ревью кода делать нереально — форматирование по каждому файлу переколбашено.
— Ну, у меня Эклипс. Это он автоматом так.
— Коля, откатываем. Нам ещё мержиться с двумя бранчами — давай формат не будем трогать.

Кейс В:
— Петя, салют. У меня опять плохие новости.
— Откатываете?
— Угадал Опять ты свой батничек поправил, а проекты Студии забыл
— Ты ж знаешь, я привык, у меня мейк настроен как надо, собирается в одно касание всё, удо...
— Петя, удобно. Тебе. Откатываем.

Здравствуйте, Donz, Вы писали:

D>И корректность коммита должна определяться не сборкой в дефолтной (опять же любимой тимлидом) IDE, а сборкой билд-сервера плюс ручным code review.

Простите, а билд-сервер чем собирает? Сферическим компилятором? Дефолтная IDE как раз и подбирается таким образом, чтобы не конфликтовать с инструментарием билд-сервера. В идеале — должна использовать тот же самый тулсет.

Насчет code review — тоже не всё так однозначно. В одном проекте было требование не выходить за 80 символов в строке (что странно звучит для нынешних мониторов, правда?). Резон оказался прост: для code review у Заказчика был в ходу какой-то инструментарий, выполненный в консольном стиле. Все "излишки" визуально обрезались

Здравствуйте, Mr.Delphist, Вы писали:

D>>И корректность коммита должна определяться не сборкой в дефолтной (опять же любимой тимлидом) IDE, а сборкой билд-сервера плюс ручным code review.
MD>Простите, а билд-сервер чем собирает? Сферическим компилятором? Дефолтная IDE как раз и подбирается таким образом, чтобы не конфликтовать с инструментарием билд-сервера. В идеале — должна использовать тот же самый тулсет.

У вас какая-то путаница. В Java мире нет жестких связей между IDE, компилятором, используемым API (можно даже подменить фундаментальную библиотеку) и какими-либо утилитами и тулзами. Все популярные IDE позволяют задать конкретный компилятор, который надо использовать. Конечный полученный байт-код не зависит от IDE, которая этот компилятор вызвала. Какие тут конфликты?
Если хотите наибольшую совместимость с окружением билд-сервера, то для этого как раз и используются сборщики проектов. Один и тот же билд-скрипт и для билд-сервера, и для локальных сборок. Из какой IDE вызывать stand-alone установленный нужной версии мавен, ант, или-что-там-еще не имеет значения. Все довольны.

MD>Насчет code review — тоже не всё так однозначно. В одном проекте было требование не выходить за 80 символов в строке (что странно звучит для нынешних мониторов, правда?). Резон оказался прост: для code review у Заказчика был в ходу какой-то инструментарий, выполненный в консольном стиле. Все "излишки" визуально обрезались

Так опять же, какая тут зависимость от IDE? Во всех средах можно настроить длину строки в символах плюс автоврапперы для различных языковых конструкций.

Здравствуйте, Mr.Delphist, Вы писали:

MD>При старте проекта утверждается дефолтный инструментарий, на котором должна быть обеспечена собираемость.
MD>Грубый пример: если мы говорим, что базовым IDE проекта будет Visual Studio 6, то стройными рядами в лес отправятся как адепты свежайших VS20xx, так и гики Эклипса и командной строки, если их жизнедеятельность будет порождать подобные кейсы.

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

MD>Кейс А:
MD>- Вася, привет
MD>- Привет
MD>- Вась, тут беда с твоим коммитом — шестерка отказывается компилить файл, хотя внешне выглядит нормально
MD>- А, понятно! Когда ж вы тоже на последнюю студию перейдёте — там юникод полностью поддерживается
MD>- Перейдем, как Заказчик одобрит бюджет на лицензии. А пока — откатываем тебя, полностью.

Значит надо обговорить версию языка и SDK, которые должны использоваться при разработке. Если Visual Studio имеет прямую зависимость от одной конкретной версии языка... То я даже не знаю, что сказать. Нет такого на яве.

MD>Кейс Б:
MD>- Коля
MD>- Ась?
MD>- Глянул твой вчерашний коммит. Там же ревью кода делать нереально — форматирование по каждому файлу переколбашено.
MD>- Ну, у меня Эклипс. Это он автоматом так.
MD>- Коля, откатываем. Нам ещё мержиться с двумя бранчами — давай формат не будем трогать.

Причем тут IDE? Во всех по умолчанию используется code style, рекомендуемый ведущим собаководом. Если хочется чего-то другого, то это обговаривается и каждый сам себе настраивает.

MD>Кейс В:
MD>- Петя, салют. У меня опять плохие новости.
MD>- Откатываете?
MD>- Угадал Опять ты свой батничек поправил, а проекты Студии забыл
MD>- Ты ж знаешь, я привык, у меня мейк настроен как надо, собирается в одно касание всё, удо...
MD>- Петя, удобно. Тебе. Откатываем.

Именно для этого существуют сборщики проектов.
Хранить в VCS файлы проектов конкретной IDE — никому ненужный геморрой. В любом случае у каждого несколько свое окружение. Я люблю проекты держать в \Donz\Projects. Кто-то в другом месте. Уже имеем не совпадение путей. У меня JDK по одному пути, у остальных по-другому. У меня сторонние утилиты лежат в одном каталоге, у Васи вообще берутся с расшаренной папки на сервере. Каждый коммит будет содержать никому ненужные конкретно твои особенности окружения.
Соответственно, каждый программист должен быть в состоянии настроить выбранную IDE.

On 18.04.2011 14:18, Mr.Delphist wrote:

> H>"С вами невозможно спорить !" (с) Но остаётся неясной связь правильной
> H>цели и стремление к тому, чтобы все пользовались одной и той же IDE (с
> H>чего всё и началось).
>
> При старте проекта утверждается дефолтный инструментарий, на котором
> должна быть обеспечена собираемость.

Ну. Этот инструментарий и называется maven
Там и кодировка исходников указывается и source и target для компиляции
и собирается всё "в одно касание". А в чём там программисты исходники
редактируют — это их личное дело.

--
WBR,
Serge.

Здравствуйте, Donz, Вы писали:

Просто сразу видно по посту, что человек разрабатыет под дотнет и там несколько другая психология, строгая что ли. Есть такая пословица — мастера узнают по инструменту. Поэтому нагибать Java разработчиков на тему IDE и форматирования это не слишком продуктивно. Если чувак не умеет настраивать эклипс, то это его проблема, что он checkstyle не проходит.

А так в принципе от тех "эффективных" лидов, которые в приказном порядке заставляют писать в определенной версии ide (к которой они привыкли), собирать батниками с их путями (к которым они привыкли) и использовать табы вместо пробелов (к которым они привыкли), надо бежать не оглядываясь.

Здравствуйте, Mr.Delphist, Вы писали:

D>>И корректность коммита должна определяться не сборкой в дефолтной (опять же любимой тимлидом) IDE, а сборкой билд-сервера плюс ручным code review.
MD>Простите, а билд-сервер чем собирает? Сферическим компилятором?
Аллё! В Java все компиляторы примерно одинаковы. Совершенно пофиг чем компилировать .java в .class.

MD>Насчет code review — тоже не всё так однозначно. В одном проекте было требование не выходить за 80 символов в строке (что странно звучит для нынешних мониторов, правда?). Резон оказался прост: для code review у Заказчика был в ходу какой-то инструментарий, выполненный в консольном стиле. Все "излишки" визуально обрезались
Для этого используются инспекции кода.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Mr.Delphist, Вы писали:

D>>>И корректность коммита должна определяться не сборкой в дефолтной (опять же любимой тимлидом) IDE, а сборкой билд-сервера плюс ручным code review.
MD>>Простите, а билд-сервер чем собирает? Сферическим компилятором?
C>Аллё! В Java все компиляторы примерно одинаковы. Совершенно пофиг чем компилировать .java в .class.

Неужели действительно одинаковы, с точностью до совместимости бинарных файлов? И можно половину файлов собрать одним компилем, а вторую — другим, и всё заработает? Блин, вы счастливые люди. Серьезно. Пора учить java.

MD>Неужели действительно одинаковы, с точностью до совместимости бинарных файлов? И можно половину файлов собрать одним компилем, а вторую — другим, и всё заработает? Блин, вы счастливые люди. Серьезно. Пора учить java.

чет я не понял, а где не так, где скомпилированное добро передается виртуальным машинам? тоись если не рассматривать всякие obj промежуточные которые совсем из другой оперы. кстати конеш подразумеваем что версия компилируемого кода соответсвуе компилеру

Здравствуйте, Mr.Delphist, Вы писали:

MD>>>Простите, а билд-сервер чем собирает? Сферическим компилятором?
C>>Аллё! В Java все компиляторы примерно одинаковы. Совершенно пофиг чем компилировать .java в .class.
MD>Неужели действительно одинаковы, с точностью до совместимости бинарных файлов?
Ага.

MD>И можно половину файлов собрать одним компилем, а вторую — другим, и всё заработает?
Можно, и я так делаю постоянно (встроеный комиплятор в IDE — это Eclipse'овый, а Maven использует javac).

Здравствуйте, Mr.Delphist, Вы писали:

MD>Здравствуйте, Cyberax, Вы писали:

C>>Здравствуйте, Mr.Delphist, Вы писали:

D>>>>И корректность коммита должна определяться не сборкой в дефолтной (опять же любимой тимлидом) IDE, а сборкой билд-сервера плюс ручным code review.
MD>>>Простите, а билд-сервер чем собирает? Сферическим компилятором?
C>>Аллё! В Java все компиляторы примерно одинаковы. Совершенно пофиг чем компилировать .java в .class.

MD>Неужели действительно одинаковы, с точностью до совместимости бинарных файлов? И можно половину файлов собрать одним компилем, а вторую — другим, и всё заработает? Блин, вы счастливые люди. Серьезно. Пора учить java.

Я ж говорю, человек запуганный майкрософтом

C>Аллё! В Java все компиляторы примерно одинаковы. Совершенно пофиг чем компилировать .java в .class.

о кстати такой вопрос эксперту.

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

Здравствуйте, keenn, Вы писали:

C>>Аллё! В Java все компиляторы примерно одинаковы. Совершенно пофиг чем компилировать .java в .class.
K>о кстати такой вопрос эксперту.
K>а разные компиляторы же могут создавать байт-код под разные jvm машины (с различной оптимизацией под то да под это)?
Байт-коду пофиг для какой он JVM. И оптимизаций в нём тоже почти что и нет (за исключением тривиальных типа dead code elimination).