Обновив недавно свою IntelliJ IDEA до 8-й версии, а также услышав о выходе долгожданной NetBeans 6.5, я естественным образом решил посмотреть, что же представляет из себя последняя, не стало ли ей возможно пользоваться и не напрасно ли я потратил очередные $149 на обновление лицензии для IDEA. Скачав и установив (и даже зарегистрировав) NetBeans, я бодро ее запустил.
Запуск прошел на удивление быстро. Настройки самой IDE и ее интеграции с JDK, базами данных и серверами приложений никаких проблем не вызвали (хотя нет, вру, одна проблема нашлась: из всех конфигураций моего JBoss'a NetBeans почему-то признала только "all", хотя ее я как раз не использую. Впрочем, расстроиться по этому поводу я не успел, потому что до момента, где мне эта интеграция могла бы понадобиться, я все равно не дошел). Покончив с настройками я, затаив дыхание, попробовал открыть один из моих текущих проектов.
Первая и последняя проблема, с которой сталкивается человек, который работает с существующим типичным JavaEE-шным проектом, собирающимся с помошью Ant, и который хочет поработать с этим проектом в NetBeans (например, в целях изучения последней с возможностью дальнейшей рекомендации начальству тотального на нее перехода в рамках всей компании) заключается в том, что этого сделать никак нельзя.
Действительно, при создании нового проекта типа "Enterprise Application" в IDE вы указываете путь к папке с существущим проектом - и немедленно (еще раз отметим быстродействие) получаете сообщение "Project folder already exists and is not empty" с невозможностью дальнейших шагов. Впрочем, на этапе выбора мы среди типов проектов видели "Enterprise application with existing sources", может быть, это то, что нам нужно?
Возвращаемся на шаг назад, выбираем этот тип и повторяем попытку (попутно отметив в описании этого типа проекта нечто вроде "The enterprise application must conform to the J2EE BluePrints Project Conventions...", но решив для себя ознакомиться этими конвенциями позже... если понадобится). Снова указываем путь к нашему проекту и тут путь нам преграждает другое сообщение: "Project Folder already contains "build.xml" file". Все. Пути дальше нет. Нет и никакой подсказки, как бы нам обойти эту маленькую проблемку. Но разве это остановит нас в нашем стойком желании оценить крутизну новой IDE?
С маниакальным упорством мы возвращаемся назад и, побродив среди различных типов проектов, находим "Java Free-Form Project", описание которого обещает нам мирно сожительствовать с существующим build.xml. И, о чудо, наш проект готов и можно, наконец, воспользоваться множеством обещанных ранее фич!
К сожалению, тут нас ждет очередной облом. Так как упомянутый "free-form" начисто лишен какой бы то ни было поддержки Java EE - это просто возможность редактировать классы исходного кода в редакторе и запускать сборку Ant'ом. Но ведь и это немало, не так ли?
Увы, даже и этой малости я оказался лишен. То есть, все было хорошо, пока не пришло время указать, что одна пачка исходников (в реальной жизни относящаяся к EJB-модулю) зависит от другой (в мире - JPA-модуль). По неосторожности (или в тайной надежде, что IDE будет отслеживать изменения исходников до их компиляции) я указал путь к исходникам, а не к скомпилированным классам, что почему-то вызвало длительную задумчивость системы при стабильной 50% загрузке процессора. На 4 минуте ожидания я оборвал эти мучения путем безжалостного убийства процесса и перезапустил NetBeans. В этот раз я был умнее и указал путь к классам, что, через несколько долгих секунд (в этом месте упомянутая ранее скорость почему-то не включалась) привело к ожидаемому результату - указания об ошибках типа "Cannot resolve symbol" исчезли. Воодушевленный этим успехом я проделал ту же операцию для исходников веб-модуля, которые зависят от обоих ранее упомянутых модулей... но в этот раз система опять впала в необъяснимую задумчивость. Убив через 5 минут процесс, я не стал перезапускать IDE, а посидел и подумал.
В конце-концов, почему бы не поступиться своим собственным build.xml, и не принять то, что мне навязывает NetBeans? А свой, например, переименовать? Или перенести куда-нибудь, а потом встроить в автоматически созданный скрипт?
Например, потому что мне нравится свой build.xml. В конце-концов, это результат многолетней оптимизации, улучшения и вылизывания, он делает то, что я хочу, так, как я хочу, и самым оптимальным, на мой взгляд, способом. И для того, чтобы собрать проект, всего-то нужно его скачать и запустить команду ant в корневом каталоге. Все необходимые условия - установленные JDK и Ant. И я совершенно не хочу поступаться этой простотой (даже если в итоге всего лишь придется запускать что-то вроде "ant -f build-mine.xml" - я не хочу это объяснять всем тем, кому придется работать над созданным мной проектом в будущем). Короче я не хочу отказываться от содержимого моего скрипта сборки и не хочу, чтобы он назывался как-то иначе.
В конце-концов, почему скрипт сборки должен одновременно служить файлом конфигурации проекта?
И почему бы разрабочикам такой навороченной IDE (а я не сомневаюсь, что она содержит множество полезных свойств и возможностей) не вспомнить, что их IDE - не первая в мире, да и Ant существует довольно-таки давно, и множество проектов использует его для сборки самым что ни на есть по умолчанию образом? Почему хотя бы не предоставить при создании проекта дополнительные опции (например, возможность переименования своего или чужого файла), раз уж случилась такая неприятность и build.xml уже существует? Почему бы не продемонстрировать своим потенциальным пользователям, что вас хоть немного интересует, насколько удобно нам будет пользоваться вашим замечательным приложением (ради которого, по идее, мы должны отказаться от какого-то другого приложения)?
В чем же тут позитив, спросят те, кто недавно выражал мне неудовольствие в связи с перекосом в сторону негатива в моем блоге? А вот в чем: $249 на покупку 7-й версии Intellij IDEA и $149 на апгрейд до 8-й потрачены не зря! Ура, товарищи!
С нежностью тыкает мышкой в зелененький треугольничек. С умилением наблюдает, как Idea сначала собирает проект с помощью моего (моего!) build.xml, потом запускает JBoss (конфигурацию "default"), разворачивает в нем только что собранное приложение и в завершение процесса открывает окно браузера точно по адресу начальной страницы развернутого приложения...
Запуск прошел на удивление быстро. Настройки самой IDE и ее интеграции с JDK, базами данных и серверами приложений никаких проблем не вызвали (хотя нет, вру, одна проблема нашлась: из всех конфигураций моего JBoss'a NetBeans почему-то признала только "all", хотя ее я как раз не использую. Впрочем, расстроиться по этому поводу я не успел, потому что до момента, где мне эта интеграция могла бы понадобиться, я все равно не дошел). Покончив с настройками я, затаив дыхание, попробовал открыть один из моих текущих проектов.
Первая и последняя проблема, с которой сталкивается человек, который работает с существующим типичным JavaEE-шным проектом, собирающимся с помошью Ant, и который хочет поработать с этим проектом в NetBeans (например, в целях изучения последней с возможностью дальнейшей рекомендации начальству тотального на нее перехода в рамках всей компании) заключается в том, что этого сделать никак нельзя.
Действительно, при создании нового проекта типа "Enterprise Application" в IDE вы указываете путь к папке с существущим проектом - и немедленно (еще раз отметим быстродействие) получаете сообщение "Project folder already exists and is not empty" с невозможностью дальнейших шагов. Впрочем, на этапе выбора мы среди типов проектов видели "Enterprise application with existing sources", может быть, это то, что нам нужно?
Возвращаемся на шаг назад, выбираем этот тип и повторяем попытку (попутно отметив в описании этого типа проекта нечто вроде "The enterprise application must conform to the J2EE BluePrints Project Conventions...", но решив для себя ознакомиться этими конвенциями позже... если понадобится). Снова указываем путь к нашему проекту и тут путь нам преграждает другое сообщение: "Project Folder already contains "build.xml" file". Все. Пути дальше нет. Нет и никакой подсказки, как бы нам обойти эту маленькую проблемку. Но разве это остановит нас в нашем стойком желании оценить крутизну новой IDE?
С маниакальным упорством мы возвращаемся назад и, побродив среди различных типов проектов, находим "Java Free-Form Project", описание которого обещает нам мирно сожительствовать с существующим build.xml. И, о чудо, наш проект готов и можно, наконец, воспользоваться множеством обещанных ранее фич!
К сожалению, тут нас ждет очередной облом. Так как упомянутый "free-form" начисто лишен какой бы то ни было поддержки Java EE - это просто возможность редактировать классы исходного кода в редакторе и запускать сборку Ant'ом. Но ведь и это немало, не так ли?
Увы, даже и этой малости я оказался лишен. То есть, все было хорошо, пока не пришло время указать, что одна пачка исходников (в реальной жизни относящаяся к EJB-модулю) зависит от другой (в мире - JPA-модуль). По неосторожности (или в тайной надежде, что IDE будет отслеживать изменения исходников до их компиляции) я указал путь к исходникам, а не к скомпилированным классам, что почему-то вызвало длительную задумчивость системы при стабильной 50% загрузке процессора. На 4 минуте ожидания я оборвал эти мучения путем безжалостного убийства процесса и перезапустил NetBeans. В этот раз я был умнее и указал путь к классам, что, через несколько долгих секунд (в этом месте упомянутая ранее скорость почему-то не включалась) привело к ожидаемому результату - указания об ошибках типа "Cannot resolve symbol" исчезли. Воодушевленный этим успехом я проделал ту же операцию для исходников веб-модуля, которые зависят от обоих ранее упомянутых модулей... но в этот раз система опять впала в необъяснимую задумчивость. Убив через 5 минут процесс, я не стал перезапускать IDE, а посидел и подумал.
В конце-концов, почему бы не поступиться своим собственным build.xml, и не принять то, что мне навязывает NetBeans? А свой, например, переименовать? Или перенести куда-нибудь, а потом встроить в автоматически созданный скрипт?
Например, потому что мне нравится свой build.xml. В конце-концов, это результат многолетней оптимизации, улучшения и вылизывания, он делает то, что я хочу, так, как я хочу, и самым оптимальным, на мой взгляд, способом. И для того, чтобы собрать проект, всего-то нужно его скачать и запустить команду ant в корневом каталоге. Все необходимые условия - установленные JDK и Ant. И я совершенно не хочу поступаться этой простотой (даже если в итоге всего лишь придется запускать что-то вроде "ant -f build-mine.xml" - я не хочу это объяснять всем тем, кому придется работать над созданным мной проектом в будущем). Короче я не хочу отказываться от содержимого моего скрипта сборки и не хочу, чтобы он назывался как-то иначе.
В конце-концов, почему скрипт сборки должен одновременно служить файлом конфигурации проекта?
И почему бы разрабочикам такой навороченной IDE (а я не сомневаюсь, что она содержит множество полезных свойств и возможностей) не вспомнить, что их IDE - не первая в мире, да и Ant существует довольно-таки давно, и множество проектов использует его для сборки самым что ни на есть по умолчанию образом? Почему хотя бы не предоставить при создании проекта дополнительные опции (например, возможность переименования своего или чужого файла), раз уж случилась такая неприятность и build.xml уже существует? Почему бы не продемонстрировать своим потенциальным пользователям, что вас хоть немного интересует, насколько удобно нам будет пользоваться вашим замечательным приложением (ради которого, по идее, мы должны отказаться от какого-то другого приложения)?
В чем же тут позитив, спросят те, кто недавно выражал мне неудовольствие в связи с перекосом в сторону негатива в моем блоге? А вот в чем: $249 на покупку 7-й версии Intellij IDEA и $149 на апгрейд до 8-й потрачены не зря! Ура, товарищи!
С нежностью тыкает мышкой в зелененький треугольничек. С умилением наблюдает, как Idea сначала собирает проект с помощью моего (моего!) build.xml, потом запускает JBoss (конфигурацию "default"), разворачивает в нем только что собранное приложение и в завершение процесса открывает окно браузера точно по адресу начальной страницы развернутого приложения...
No comments:
Post a Comment