Комментарии 20
Аааа, mammoth shit!
Вероятно, стоит поправить блок «Поддерживаемые форматы приложений», то непереведённый кусочек смотрится странно.
Вероятно, стоит поправить блок «Поддерживаемые форматы приложений», то непереведённый кусочек смотрится странно.
Мне кажется, что данный блок лучше оставить в исходном виде, уж больно специфические вещи в нем описаны.
Ведь лучше так:
the SAR application archive
Чем как-то так:
приложение в архиве формата SAR или SAR архив-приложение
Ведь лучше так:
the SAR application archive
Чем как-то так:
приложение в архиве формата SAR или SAR архив-приложение
Как минимум можно перевести
А по первой части можно написать в стиле WAR (Webapp ARchive), SAR (Service ARchive), EAR (Enterprise ARchive).
The *-ds.xml file defines connections to external databases;
XML files with MBean service definitions;
JAR files containing EJBs or other service objects directly in JBoss AS
А по первой части можно написать в стиле WAR (Webapp ARchive), SAR (Service ARchive), EAR (Enterprise ARchive).
JBOSS 4 — эх, молодость! джуниорство босоногое)
Вот, если бы этому мануалу дали продолжения, золотой ман получился бы :)
JBOSS: Jmx-Console и JMXInvokerServlet. Сколько же серверов было взломано и забекдорено благодаря JBOSS. Черви, шеллы, руты… Ностальгия. JBOSS, cпасибо тебе, за такие простые и эффективные механизмы pwnage и внимательных админов, что читают мануалы!
Красава, пока что один из лучших туториолов о жбоссу. Но уже конечно эра 7го на дворе, а там и WildFly уже родился.
Где мои семнадцать лет )) Помню, мы в итоге отказались от JBOSS, т.к. красная шапка не публиковала сорцы для патчей. Можно было, конечно, годами ждать major releases, либо судиться с Red Hat ввиду явного нарушения LGPL… Но проще оказалось мигрировать на другой продукт.
Интересно, JBoss EAP по-прежнему нельзя собрать из сорцов, или что-то поменялось?
Интересно, JBoss EAP по-прежнему нельзя собрать из сорцов, или что-то поменялось?
Сейчас можно, но готовых скриптов для сборки никто не предоставлял. По крайней мере, для jboss as 7.1.
Скрипты для jboss AS ничем не привлекательны. Это community edition, для которой и так доступны официальные сборки. Вот только релизов надо ждать годами.
В то же время, коммерческий вариант EAP обновляется гораздо чаще. Понятно, что готовые сборки без лицензии не получить. Но LGPL обязует публиковать сорцы. Вот только не знаю, выполняет ли Red Hat на сегодняшний день свои обязательства.
В то же время, коммерческий вариант EAP обновляется гораздо чаще. Понятно, что готовые сборки без лицензии не получить. Но LGPL обязует публиковать сорцы. Вот только не знаю, выполняет ли Red Hat на сегодняшний день свои обязательства.
Вы говорите про всю платформу (включая всякий мониторинг, web framework kit) или только appserver, входящий в EAP?
Если только appserver, то его исходники лежат тут: ftp.redhat.com/redhat/jbeap/6.3.1/en/source/, необходимые артефакты для сборки лежат тут maven.repository.redhat.com/techpreview/eap6/6.3.1/. Если лень собирать самому — есть. например, github.com/hasalex/eap-build от Alexis Hassler, который гуглится первой ссылкой по «build jboss eap».
Jboss AS 7.2.0.Final, соответствующий JBoss EAP 6.1.0.GA доступен на GH и собирается мавеном. Как-то патчил и собирал без проблем.
А в чём они нарушали LGPL? Они не предоставляли исходники подписчикам?
У меня из возможностей jboss as 7 использовались только базовые (servlet, jax-rs, cdi), но я переехал на голый tomcat/jetty, т. к. хотелось независимых от jboss'а версий weld, resteasy, jackson, slf4j и т. д. Оно не на много сложнее, но проблем меньше.
Если только appserver, то его исходники лежат тут: ftp.redhat.com/redhat/jbeap/6.3.1/en/source/, необходимые артефакты для сборки лежат тут maven.repository.redhat.com/techpreview/eap6/6.3.1/. Если лень собирать самому — есть. например, github.com/hasalex/eap-build от Alexis Hassler, который гуглится первой ссылкой по «build jboss eap».
Jboss AS 7.2.0.Final, соответствующий JBoss EAP 6.1.0.GA доступен на GH и собирается мавеном. Как-то патчил и собирал без проблем.
А в чём они нарушали LGPL? Они не предоставляли исходники подписчикам?
У меня из возможностей jboss as 7 использовались только базовые (servlet, jax-rs, cdi), но я переехал на голый tomcat/jetty, т. к. хотелось независимых от jboss'а версий weld, resteasy, jackson, slf4j и т. д. Оно не на много сложнее, но проблем меньше.
Хорошие ссылки, беру к себе в копилку. Возможно пригодится в следующем проекте.
У Вас, похоже, небольшое несоответствие: официальный faq утверждает, что Jboss AS 7.2.0.Final, соответствует JBoss EAP 6.1.0.Alpha, а не 6.1.0.GA, как у вас.
И да, LGPL обязует публиковать сорцы. Причем не только для подписчиков, а для всех. Если собрать из сорцов EAP 6.3.0 свой билд, то можно легально использовать его в production environment без всякой подписки.
У Вас, похоже, небольшое несоответствие: официальный faq утверждает, что Jboss AS 7.2.0.Final, соответствует JBoss EAP 6.1.0.Alpha, а не 6.1.0.GA, как у вас.
И да, LGPL обязует публиковать сорцы. Причем не только для подписчиков, а для всех. Если собрать из сорцов EAP 6.3.0 свой билд, то можно легально использовать его в production environment без всякой подписки.
Я ориентировался на jbossas.jboss.org/downloads, где про EAP 6.1.0 Alpha сказано, что оно на основе AS7, а про GA, что оно на основе 7.2. Наиболее точную информацию по компонентам нашел тут: access.redhat.com/articles/112673.
Как я вижу, даже в случае GPL, нет обязанности отдавать собранную программу и/или исходники всем. www.gnu.org/licenses/gpl-faq.html#DoesTheGPLRequireAvailabilityToPublic
Но, при этом, держатель копии программы под GPL не обязан делиться копиями с кем бы то ни было, хотя и имеет право на это. www.gnu.org/licenses/gpl-faq.html#CompanyGPLCostsMoney
Как я вижу, даже в случае GPL, нет обязанности отдавать собранную программу и/или исходники всем. www.gnu.org/licenses/gpl-faq.html#DoesTheGPLRequireAvailabilityToPublic
Но, при этом, держатель копии программы под GPL не обязан делиться копиями с кем бы то ни было, хотя и имеет право на это. www.gnu.org/licenses/gpl-faq.html#CompanyGPLCostsMoney
Как я вижу, даже в случае GPL, нет обязанности отдавать собранную программу и/или исходники всем. www.gnu.org/licenses/gpl-faq.html#DoesTheGPLRequireAvailabilityToPublic
Прочитайте внимательно вопрос из Вашей ссылки. Распространение GPL'd software for a fee действительно ни к чему не обязывает.
Но случае изменений в (L)GPL коде, есть прямая обязанность открыть исходники. В этом, собственно, вся суть GNU лицензий.
Но случае изменений в (L)GPL коде, есть прямая обязанность открыть исходники. В этом, собственно, вся суть GNU лицензий.Только тем, кто легально получил копию программы. Суть GPL — в наборе свобод, а не в бесплатности (которое необязательное). Исходники требуются для свободы изучения/модификации, в первую очередь.
Если вы легально получили бинарную сборку и/или исходники (которые, например, доступны со страницы jbossas.jboss.org/downloads), то coryright не запрещает вам это распространять. Но стоит учитывать, что в этом случае вы явным образом нарушаете EULA и часть законодательства по товарным знакам. Но вы имеете полное право вырезать их и пересобрать EAP. Это явно указано в EULA.
Также приведу фрагмент из этого поста:
Essentially we give you three choices:
1. Stick with community — You get always get the latest and greatest cutting edge stuff (including experimental features), but you have to get support from the community and update more frequently since the community really only focuses on the latest major + minor version.
2. Buy an EAP subscription — You get all of the features above, which lead to minimizing the amount of work you need to spend on app server maintenance and support.
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'ам).
Но случае изменений в (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'ам).
Я ни слова не написал про распространение ПО. Вы же возвращаетесь к этому сценарию второй раз. Зачем?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
JBOSS 4.2.3 Manual