>Ваши аргументы сводятся к вашему личному опыту сравнения с решениями, написанными по-ходу неквалифицированными программистами. И Вы делаете вывод, что виновато отсутствие JEE. Отчасти, конечно, Вы правы.
А я и не говорю, что я везде прав. Это, если угодно, был намек. что программисты у нас такие, какие есть. И не у нас тоже — подрядчики не лучше, я видел вживую, какого качества код пишут в IBM, лучше бы его развидеть. Набрать где-то лучше — это зачастую большущая проблема. Набрать таких, которые способны реализовать сами контейнер — ну вы сами только что написали, что мало кто понимает, как он работает. Не видите противоречия? )))
Слушайте, ну не надо утрировать. Я вам могу еще раз повторить — у меня было с десяток вполне успешных проектов сравнительно разного размера, и нигде, повторяю — нигде выбор JavaEE не был основан на том, что дядя купил Weblogic. Его выбрали разработчики. А поскольку проекты были успешные — то выбор был правилен.
Выбрал бы я его сейчас? А вот не факт. Может быть выбрал бы karaf — но при этом нормального JavaEE уровня реализации многих вещей я там не вижу.
А все ваши соображения — они вполне себе разумные и не вызывают отторжения — если выводы не обобщать на все проекты и всех разработчиков. Потому что «без нормальных тестов» — это давно неправда. Где-то с EJB 3 примерно.
Ну, с ant проще перевести на что угодно. Реальные проблемы в сборке обычно начинаются тогда, когда у нас в проекте кучка зависимостей, как внешних, так и внутренних, которые обновляются время от времени, и надо следить за их версиями, их совместимостью и т.п.
ant этого всего почти не умеет (даже с ivy). gradle и maven умеют, но делают по разному, я не могу сказать, что какой-то подход заведомо лучше. Лично для себя я предпочитаю maven, по той простой причине, что формат pom.xml — он читается любым инструментом, на любом языке, gradle же неявно предполагает, что у вас есть сам gradle, и почитать скажем метаданные проекта без него — это целая история (и кстати, в репозиторий обычно кладут все тот же pom).
Стандартный ответ — вы обобщаете свой ограниченный опыт на всех, и делаете ошибку. Нет, не JTA вовсе. А скорее управляемость кода в целом, как при разработке, так и в эксплуатации. В самом широком смысле.
История о том, что все глухо лежит, пока не разбудят админа, больше всего похожа на байку. Я лично про такое никогда не слышал — просто потому, что таймауты никто не отменял. А я уже с 2000 года на J2EE. Начиная с EJB 2, который реально был так себе. Только это давно неправда.
remote EJB нарушает транзакционность? С каких это пор? Где вы взяли такой фиговый контейнер?
А насчет лучше и проще… ну может в вашем мире так, а я повторюсь, все крупные проекты, которые я видел и которые были сделаны без контейнера (на сегодня это либо JavaEE либо OSGI) — на них смотреть было больно. Именно потому, все все, буквально, что было изобретено на замену штатным средствам JavaEE, все не работало. В одном своем проекте у меня было примерно полсотни мелких компонент, из которых где-то 40 жили в Weblogic, а остальные 10 были standalone приложениями. Так вот, мороки с этими десятью было не в пример больше — при том что по сложности они были несравнимо меньше.
Так что для меня контейнер дает совсем другое — причем простое и очевидно. Модульность — в виде каких-либо стандартных компонент, которе начиная с EJB3 пишутся легко и непринужденно, а до этого делались с помощью спринга, обозримость runtime в целом, когда контейнер предоставляет скажем консоль, откуда можно посмотреть JMX и порулить ими, запустить и остановить компоненты, и прочая. И когда у вас в проекте этих компонент с полсотни — это уже нифига не мелочи. Попробуйте на пару сотен микросервисов просто порты пораспределять без инструмента — и каково оно?
Короче — я не вижу этого вашего «лучше и проще». Может оно и существует где-то (скажем, для высоконагруженных приложений) — а в среднем проекте, где нагрузки особой нет, пользователей скажем тысяч десять (а это, между прочим, масштаб интранета крупнейших банков), из велосипедов получается одно барахло.
Гм. Вот знаете, у нас в соседнем проекте оказывается собирали все maven второй версии. Я уже забыл, когда у меня он был, лет семь наверное прошло с тех пор. При этом оно а) работает б) с тем же репозиторием в) разницы в pom.xml нет никакой. Инструменту 10 лет, он используется, и все довольны.
А посмотришь зачастую в проект на github, а там: «Мигрировали с версии gradle xxx на yyy», через полгода еще раз… потом еще. Большая часть коммитов — такие. И кому нужно такое «развитие» с позволения сказать, которое требует проект раз в полгода переделывать? Чему тут развиваться, если сам проект остался таким же? Система сборки не требует такого, и не должна.
Ктож вас-то заставляет монолитное писать? Кстати, если в проекте нет контейнера — то с модульностью там обычно все еще хуже, чем когда он есть. А все без исключения виденные мной лично попытки заменить Java EE своим велосипедом как правило были намного хуже — впрочем, я это и сегодня живьем наблюдаю. Какой только фигни там не встретишь.
Часто? Я вот видел подход десятка крупнейших банков. Он бывал любой — от «используйте то, что считаете нужным, включая опенсорс» до «ваш выбор Weblogic такой-то версии». Покупной софтины требующей сервера вообще ни видел никогда — обычно сервер просто входит в ее комплект (это IBM BPM к примеру — вебсфера внутри). Покупали вообще мало — значительно больше делают сами. Выбор Java EE всегда был осознанным и своим (хотя и не всегда все с этим были согласны). А все известные попытки написать свой велосипед с транзакциями и JMS на коленке — провалились.
А оно хоть стало лучше по сравнению с предыдущими версиями? Потому что попытки запустить кажется версию 2 на рабочей машине с 8gb и i7 как-то закончились совсем грустно.
Репозиторий maven central сопровождает компания sonatype, кстати, вполне себе коммерческая (продает тот же repository manager, например).
Они сами вполне однозначно высказались по поводу данного инцидента, и я советую их пост просто прочитать.
Насколько я понимаю, ситуация типа той, что была с kik, ровно в таком же виде невозможна (потому что пакеты именуются как домены, и чтобы опубликовать пакет com.kik, нужно подтвердить, что ты владелец домена). И потом у тебя права на эти пакеты просто так не отнимут.
Ну и насчет удаления — его реально нет. И это четкая позиция держателя репозитория — если пакет (версию) опубликовали один раз, от него могут зависеть сколько угодно проектов, и никто не знает, сколько их. Поэтому удалять его, и даже публиковать измененную версию запрещено — если очень хочется, публикуйте новую.
А я и не говорю, что я везде прав. Это, если угодно, был намек. что программисты у нас такие, какие есть. И не у нас тоже — подрядчики не лучше, я видел вживую, какого качества код пишут в IBM, лучше бы его развидеть. Набрать где-то лучше — это зачастую большущая проблема. Набрать таких, которые способны реализовать сами контейнер — ну вы сами только что написали, что мало кто понимает, как он работает. Не видите противоречия? )))
Выбрал бы я его сейчас? А вот не факт. Может быть выбрал бы karaf — но при этом нормального JavaEE уровня реализации многих вещей я там не вижу.
А все ваши соображения — они вполне себе разумные и не вызывают отторжения — если выводы не обобщать на все проекты и всех разработчиков. Потому что «без нормальных тестов» — это давно неправда. Где-то с EJB 3 примерно.
Java 7, извините. С весны прошлого года.
ant этого всего почти не умеет (даже с ivy). gradle и maven умеют, но делают по разному, я не могу сказать, что какой-то подход заведомо лучше. Лично для себя я предпочитаю maven, по той простой причине, что формат pom.xml — он читается любым инструментом, на любом языке, gradle же неявно предполагает, что у вас есть сам gradle, и почитать скажем метаданные проекта без него — это целая история (и кстати, в репозиторий обычно кладут все тот же pom).
История о том, что все глухо лежит, пока не разбудят админа, больше всего похожа на байку. Я лично про такое никогда не слышал — просто потому, что таймауты никто не отменял. А я уже с 2000 года на J2EE. Начиная с EJB 2, который реально был так себе. Только это давно неправда.
remote EJB нарушает транзакционность? С каких это пор? Где вы взяли такой фиговый контейнер?
А насчет лучше и проще… ну может в вашем мире так, а я повторюсь, все крупные проекты, которые я видел и которые были сделаны без контейнера (на сегодня это либо JavaEE либо OSGI) — на них смотреть было больно. Именно потому, все все, буквально, что было изобретено на замену штатным средствам JavaEE, все не работало. В одном своем проекте у меня было примерно полсотни мелких компонент, из которых где-то 40 жили в Weblogic, а остальные 10 были standalone приложениями. Так вот, мороки с этими десятью было не в пример больше — при том что по сложности они были несравнимо меньше.
Так что для меня контейнер дает совсем другое — причем простое и очевидно. Модульность — в виде каких-либо стандартных компонент, которе начиная с EJB3 пишутся легко и непринужденно, а до этого делались с помощью спринга, обозримость runtime в целом, когда контейнер предоставляет скажем консоль, откуда можно посмотреть JMX и порулить ими, запустить и остановить компоненты, и прочая. И когда у вас в проекте этих компонент с полсотни — это уже нифига не мелочи. Попробуйте на пару сотен микросервисов просто порты пораспределять без инструмента — и каково оно?
Короче — я не вижу этого вашего «лучше и проще». Может оно и существует где-то (скажем, для высоконагруженных приложений) — а в среднем проекте, где нагрузки особой нет, пользователей скажем тысяч десять (а это, между прочим, масштаб интранета крупнейших банков), из велосипедов получается одно барахло.
А посмотришь зачастую в проект на github, а там: «Мигрировали с версии gradle xxx на yyy», через полгода еще раз… потом еще. Большая часть коммитов — такие. И кому нужно такое «развитие» с позволения сказать, которое требует проект раз в полгода переделывать? Чему тут развиваться, если сам проект остался таким же? Система сборки не требует такого, и не должна.
Они сами вполне однозначно высказались по поводу данного инцидента, и я советую их пост просто прочитать.
Насколько я понимаю, ситуация типа той, что была с kik, ровно в таком же виде невозможна (потому что пакеты именуются как домены, и чтобы опубликовать пакет com.kik, нужно подтвердить, что ты владелец домена). И потом у тебя права на эти пакеты просто так не отнимут.
Ну и насчет удаления — его реально нет. И это четкая позиция держателя репозитория — если пакет (версию) опубликовали один раз, от него могут зависеть сколько угодно проектов, и никто не знает, сколько их. Поэтому удалять его, и даже публиковать измененную версию запрещено — если очень хочется, публикуйте новую.