Но случае изменений в (L)GPL коде, есть прямая обязанность открыть исходники. В этом, собственно, вся суть GNU лицензий.
Только тем, кто легально получил копию программы.
Вы заблуждаетесь. Открытие кода, это не обязательство перед покупателями продукта.
3. Self build and support EAP — You get some of the benefits of the enterprise releases (e.g. patches to older major versions and so on), but you have to invest time and energy to build and maintain/verify your app server distribution bits.
Это именно тот вариант, о котором я говорю с самого начала.
Ситуация очень напоминает Firefox-Iceweasel. И то, и другое под MPL, но первый нельзя распространять на некоторых условиях (из-за ограничений по trademark'ам).
Я ни слова не написал про распространение ПО. Вы же возвращаетесь к этому сценарию второй раз. Зачем?
Хорошие ссылки, беру к себе в копилку. Возможно пригодится в следующем проекте.
У Вас, похоже, небольшое несоответствие: официальный faq утверждает, что Jboss AS 7.2.0.Final, соответствует JBoss EAP 6.1.0.Alpha, а не 6.1.0.GA, как у вас.
И да, LGPL обязует публиковать сорцы. Причем не только для подписчиков, а для всех. Если собрать из сорцов EAP 6.3.0 свой билд, то можно легально использовать его в production environment без всякой подписки.
Скрипты для jboss AS ничем не привлекательны. Это community edition, для которой и так доступны официальные сборки. Вот только релизов надо ждать годами.
В то же время, коммерческий вариант EAP обновляется гораздо чаще. Понятно, что готовые сборки без лицензии не получить. Но LGPL обязует публиковать сорцы. Вот только не знаю, выполняет ли Red Hat на сегодняшний день свои обязательства.
Где мои семнадцать лет )) Помню, мы в итоге отказались от JBOSS, т.к. красная шапка не публиковала сорцы для патчей. Можно было, конечно, годами ждать major releases, либо судиться с Red Hat ввиду явного нарушения LGPL… Но проще оказалось мигрировать на другой продукт.
Интересно, JBoss EAP по-прежнему нельзя собрать из сорцов, или что-то поменялось?
Просто и гениально! Кавай! Чтобы повысить «емкость», можно ставить тэги не только на левом краю страничек, но также у верхнего и нижнего края. Еще можно добавить цвет и завести, например, синий регистр, красный и зеленый.
А где multiset, он же bag, я вас спрашиваю?! Уж если затронули такие свойства как unique/non-unique и ordered/non-ordered, то извольте расписать все четыре варианта.
Jackson гораздо популярнее gson. Посему автор вопроса вполне справедливо посчитал, что автор статьи имел возможность ознакомиться с обеими альтернативами, и поделится с нами результатами своего сравнительного анализа. Почитать этот анализ было бы гораздо интереснее, нежели никчемные ответы на вопросы, которые не Вам задавали, и не менее скучные возгласы на тему того, что и как часто Вас удивляет.
Интересное начало! Мы сейчас как раз на распутье, рассматриваем разные ESB. После первой итерации и сравнения разных решений очень убедительно выглядит ServiceMix и его дерриваты (JBoss Fuse, fabric8, Talend ESB). Если коротко, ServiceMix это не только верблюд, но и 3-4 кг диетического, легкоусвояемого мяса но это очень удачная связка, которая включает в себя:
— ActiveMQ, надежный JMS брокер, настроенный «под ключ»
— Apache CXF, для WS‐* and RESTful services
— Karaf, легкий osgi контейнер, который вмещает в себя весь этот зоопарк, и, видимо, упрощает его администрирование
Вы на верном пути! Читайте больше и чаще. Со временем это занятие положительно скажется на Вашей орфографии и пунктуации. Возможно, даже на смысловой нагрузке Ваших комментариев.
> Вообще-то для этого не требуются AST трансформации
AST трансформации, формально, вообще нигде не требуются. Но они уменьшают количество boilerplate-кода, и это, согласитесь, здорово.
Ваше решение, как и многие другие не избавлено от этого недостатка. Приходится создавать вспомогательные методы или классы.
Скорее всего я найду свободное время чтобы расчехлить AST и «спрятать» весь boilerplate в моей текущей реализации bidirectional assocations с глаз долой. Первым комментарием хотел лишь внести для себя определенность, что не изобрету тем самым велосипед.
Вангую дальнейшее развитие интерфейса, голографическая картинка, запахи ингредиентов, тактильный фидбек. Наконец, лет через 30 непрерывного технологического прогресса, нанотехнологии достигнут своего апогея; юзер получит возможность немыслимую доселе возможность: кидать дольки НАСТОЯЩЕГО шампиньона на кусок НАСТОЯЩЕГО теста, все это в живом времени и высоком разрешении. Эх, мечты, мечты…
Возможно, Вы имели ввиду не hamster, а hamcrest? Если да, то полностью поддерживаю. Очень ценю hamcrest как гибкое средство построения сложных ассертов, и не в последнюю очередь как источник внятных сообщений об ошибках.
В контексте статьи хочу также добавить, что hamcrest вкупе с мавеном позволяли мне до сих пор менять junit на tesng и наоборот без особых проблем.
Нет-нет. Вы не совсем поняли. Речь идет не об открытых, а именно о закрытых, private полях. Проведите параллель между object/object мэппином и object/database мэппином, таким, например, как JPA.
В JPA, к счастью, не возбраняется инициализация приватных полей сущности «напрямую». Это может на первый взгляд показаться насильственным нарушением правил инкапсуляции. Но при более внимательном рассмотрении все оказывается с точностью до наоборот. Именно способность фреймворка добраться до приватных полей напрямую позволяет нам убрать все лишние геттеры/сеттеры, а значит защитить внутреннее состояние объекта от внешнего client-кода.
После появления в дозере аннотации @Mapping с облегчением вздохнул… и выкинул все лишние геттеры/сеттеры из presentation- и business- объектов. Отсюда вопрос автору топика: Ваш велосипед умеет переносить внутреннее состояние между объектами, минуя геттеры/сеттеры?
«паушально уже попадаете на деньги» — боже, какой дикий суржик… По теме: если говорить о Германии, то указанный Вами сбор (именно сбор — не налог) был придуман для того, чтобы телевизионные СМИ и культурно-образовательное телевещание были полностью независимы от гос. структур. В России мы тоже платим за телевещание, но непрозрачно, через систему налогообложения.
Основная проблема вот в чем: тем, кто у руля, проще простого погрозить пальчиком или даже урезать бюджет всем, кто вещает «неправильные» новости, нарушает продиктованную цензуру, недостаточно часто рассказывает нам про освящение богоугодных артиллерийских орудий, про удои, овощи там, рожь, вот это все.
Вы заблуждаетесь. Открытие кода, это не обязательство перед покупателями продукта.
Это именно тот вариант, о котором я говорю с самого начала.
Я ни слова не написал про распространение ПО. Вы же возвращаетесь к этому сценарию второй раз. Зачем?
Прочитайте внимательно вопрос из Вашей ссылки. Распространение GPL'd software for a fee действительно ни к чему не обязывает.
Но случае изменений в (L)GPL коде, есть прямая обязанность открыть исходники. В этом, собственно, вся суть GNU лицензий.
У Вас, похоже, небольшое несоответствие: официальный faq утверждает, что Jboss AS 7.2.0.Final, соответствует JBoss EAP 6.1.0.Alpha, а не 6.1.0.GA, как у вас.
И да, LGPL обязует публиковать сорцы. Причем не только для подписчиков, а для всех. Если собрать из сорцов EAP 6.3.0 свой билд, то можно легально использовать его в production environment без всякой подписки.
В то же время, коммерческий вариант EAP обновляется гораздо чаще. Понятно, что готовые сборки без лицензии не получить. Но LGPL обязует публиковать сорцы. Вот только не знаю, выполняет ли Red Hat на сегодняшний день свои обязательства.
Интересно, JBoss EAP по-прежнему нельзя собрать из сорцов, или что-то поменялось?
но и 3-4 кг диетического, легкоусвояемого мясано это очень удачная связка, которая включает в себя:— ActiveMQ, надежный JMS брокер, настроенный «под ключ»
— Apache CXF, для WS‐* and RESTful services
— Karaf, легкий osgi контейнер, который вмещает в себя весь этот зоопарк, и, видимо, упрощает его администрирование
А какая у Вас обвязка вокруг Camel?
Но кроме шуток, Вы можете как-то по-существу позиционировать Ваш проект относительно mucommander?
Хорошая попытка, но нет. Пожар в теплице Икарус-II не забыт!
#irony off
AST трансформации, формально, вообще нигде не требуются. Но они уменьшают количество boilerplate-кода, и это, согласитесь, здорово.
Ваше решение, как и многие другие не избавлено от этого недостатка. Приходится создавать вспомогательные методы или классы.
Скорее всего я найду свободное время чтобы расчехлить AST и «спрятать» весь boilerplate в моей текущей реализации bidirectional assocations с глаз долой. Первым комментарием хотел лишь внести для себя определенность, что не изобрету тем самым велосипед.
но чтобы было достаточно любой из этих срок, для установления двусторонней связи между container и item?
В контексте статьи хочу также добавить, что hamcrest вкупе с мавеном позволяли мне до сих пор менять junit на tesng и наоборот без особых проблем.
В JPA, к счастью, не возбраняется инициализация приватных полей сущности «напрямую». Это может на первый взгляд показаться насильственным нарушением правил инкапсуляции. Но при более внимательном рассмотрении все оказывается с точностью до наоборот. Именно способность фреймворка добраться до приватных полей напрямую позволяет нам убрать все лишние геттеры/сеттеры, а значит защитить внутреннее состояние объекта от внешнего client-кода.
Основная проблема вот в чем: тем, кто у руля, проще простого погрозить пальчиком или даже урезать бюджет всем, кто вещает «неправильные» новости, нарушает продиктованную цензуру, недостаточно часто рассказывает нам про освящение богоугодных артиллерийских орудий, про удои, овощи там, рожь, вот это все.