Почему нет полезного пакета JBoss?

Попробовав сам пакет jboss, я уверен, что знаю, почему для него нет хорошего пакета.

Тем не менее, я работал над созданием такого пакета. Я «работаю над этим» уже два года, хотя сейчас мне это нужно. Надеюсь, скоро будет PPA. :-) Если вы уже делали упаковку .deb и знаете внутренности JBoss, возможно, мы можем сотрудничать.

Попробовав сам пакет jboss, я уверен, что знаю, почему для него нет хорошего пакета.

Тем не менее, я работал над созданием такого пакета. Я «работаю над этим» уже два года, хотя сейчас мне это нужно. Надеюсь, скоро будет PPA. :-) Если вы уже делали упаковку .deb и знаете внутренности JBoss, возможно, мы можем сотрудничать.

Попробовав сам пакет jboss, я уверен, что знаю, почему для него нет хорошего пакета.

Тем не менее, я работал над созданием такого пакета. Я «работаю над этим» уже два года, хотя сейчас мне это нужно. Надеюсь, скоро будет PPA. :-) Если вы уже делали упаковку .deb и знаете внутренности JBoss, возможно, мы можем сотрудничать.

Попробовав сам пакет jboss, я уверен, что знаю, почему для него нет хорошего пакета.

Тем не менее, я работал над созданием такого пакета. Я «работаю над этим» уже два года, хотя сейчас мне это нужно. Надеюсь, скоро будет PPA. :-) Если вы уже делали упаковку .deb и знаете внутренности JBoss, возможно, мы можем сотрудничать.

Попробовав сам пакет jboss, я уверен, что знаю, почему для него нет хорошего пакета.

Тем не менее, я работал над созданием такого пакета. Я «работаю над этим» уже два года, хотя сейчас мне это нужно. Надеюсь, скоро будет PPA. :-) Если вы уже делали упаковку .deb и знаете внутренности JBoss, возможно, мы можем сотрудничать.

Попытавшись сам пакет jboss, я уверен, что знаю, почему для него нет хорошего пакета.

1. Требования к бизнесу. Это продукт «предприятия-иш» RedHat. Ubuntu - дистрибутив Debian-esque. Таким образом, не многие люди используют его на Ubuntu или Debian, потому что большинство людей, которые хотят иметь «корпоративный» бит, также хотят, чтобы корпоративная поддержка, и подумайте, что лучше всего пойти RedHat.
2. Stricter требования. Вы взглянули на пакет tomcat? Это беспорядок. По всему месту. Распространение tarcat tarball (и пакет RedHat, если на то пошло) помещает все в / usr / share, последний раз я проверил, что было пару лет назад. Напротив, пакеты Debian / Ubuntu имеют переменные данные в / var / lib / tomcat * (CATALINA_HOME), статические java-библиотеки в / usr / share / tomcat * (TOMCAT_HOME), JNI в / usr / lib / tomcat *, и используйте символические ссылки, чтобы связать все это вместе. Это связано с тем, что пакет Debian предназначен для установки одной установки tomcat для работы с несколькими экземплярами tomcat, а также потому, что требования к упаковке более строгие для Debian / Ubuntu и на самом деле настаивают на том, что конфигурация находится в / etc, переменные данные находятся в / var и т. д. RedHat не имеет таких требований, и дистрибутив JBoss скорее объединяет все вместе так, как это трудно вынести.
3. Перфекционизм перед лицом плохой / несуществующей документации. Если вы посмотрите на пакеты Debian / Ubuntu для libjboss- *, вы увидите, что все библиотеки являются отдельными пакетами. Это потому, что они на самом деле не один продукт, а их коллекция, которые просто работают вместе. В стандартном архиве JBoss у вас есть «по умолчанию» и «все» (и «минимальные», я думаю ...), которые представляют собой несколько «примерных» комбинаций ... но на самом деле возможны многие комбинации. Я уверен, что упаковщик знает об этом и пытается установить только те библиотеки, которые вам нужны в системе JBoss, как хорошая практика (но почти никогда не соблюдалась, в случае JBoss, где почти каждый просто использует пример «все»).
4. Сложность интеграции. Нет сценариев запуска службы, которые находятся где-то рядом с уровнем сложности, который является нормальным в Ubuntu. Сам процесс сервера просто плюется на stdout, даже. Вам нужно будет найти способы перенаправления на файлы журналов с возможностью поворота, настроить cron / logwatch, чтобы справиться с ним, написать сценарий инициализации и т. Д. Это не тривиально, особенно учитывая, что JBoss - это коллекция «любых» библиотек, которые пользователь решает использовать, и not , разработанных с учетом системных установок, - это, безусловно, «запуск этого из вашего домашнего каталога» типа установки из коробки.
5. Отсутствие необходимости. Tarball, помещенный в / opt, возможно, с checkinstall , выполняет работу для тех, кто действительно осуществляет широкомасштабные развертывания. Если вы занимаетесь крупномасштабными развертываниями, у вас обычно есть свой собственный репозиторий пакетов, поэтому еще одна проблема не слишком важна. Просто недостаточно сделать для него хороший пакет.

Тем не менее, я работал над созданием такого пакета. Я «работаю над этим» уже два года, хотя сейчас мне это нужно. Надеюсь, скоро будет PPA. :-) Если вы уже делали упаковку .deb и знаете внутренности JBoss, возможно, мы можем сотрудничать.

Попытавшись сам пакет jboss, я уверен, что знаю, почему для него нет хорошего пакета.

1. Требования к бизнесу. Это продукт «предприятия-иш» RedHat. Ubuntu - дистрибутив Debian-esque. Таким образом, не многие люди используют его на Ubuntu или Debian, потому что большинство людей, которые хотят иметь «корпоративный» бит, также хотят, чтобы корпоративная поддержка, и подумайте, что лучше всего пойти RedHat.
2. Stricter требования. Вы взглянули на пакет tomcat? Это беспорядок. По всему месту. Распространение tarcat tarball (и пакет RedHat, если на то пошло) помещает все в / usr / share, последний раз я проверил, что было пару лет назад. Напротив, пакеты Debian / Ubuntu имеют переменные данные в / var / lib / tomcat * (CATALINA_HOME), статические java-библиотеки в / usr / share / tomcat * (TOMCAT_HOME), JNI в / usr / lib / tomcat *, и используйте символические ссылки, чтобы связать все это вместе. Это связано с тем, что пакет Debian предназначен для установки одной установки tomcat для работы с несколькими экземплярами tomcat, а также потому, что требования к упаковке более строгие для Debian / Ubuntu и на самом деле настаивают на том, что конфигурация находится в / etc, переменные данные находятся в / var и т. д. RedHat не имеет таких требований, и дистрибутив JBoss скорее объединяет все вместе так, как это трудно вынести.
3. Перфекционизм перед лицом плохой / несуществующей документации. Если вы посмотрите на пакеты Debian / Ubuntu для libjboss- *, вы увидите, что все библиотеки являются отдельными пакетами. Это потому, что они на самом деле не один продукт, а их коллекция, которые просто работают вместе. В стандартном архиве JBoss у вас есть «по умолчанию» и «все» (и «минимальные», я думаю ...), которые представляют собой несколько «примерных» комбинаций ... но на самом деле возможны многие комбинации. Я уверен, что упаковщик знает об этом и пытается установить только те библиотеки, которые вам нужны в системе JBoss, как хорошая практика (но почти никогда не соблюдалась, в случае JBoss, где почти каждый просто использует пример «все»).
4. Сложность интеграции. Нет сценариев запуска службы, которые находятся где-то рядом с уровнем сложности, который является нормальным в Ubuntu. Сам процесс сервера просто плюется на stdout, даже. Вам нужно будет найти способы перенаправления на файлы журналов с возможностью поворота, настроить cron / logwatch, чтобы справиться с ним, написать сценарий инициализации и т. Д. Это не тривиально, особенно учитывая, что JBoss - это коллекция «любых» библиотек, которые пользователь решает использовать, и not , разработанных с учетом системных установок, - это, безусловно, «запуск этого из вашего домашнего каталога» типа установки из коробки.
5. Отсутствие необходимости. Tarball, помещенный в / opt, возможно, с checkinstall , выполняет работу для тех, кто действительно осуществляет широкомасштабные развертывания. Если вы занимаетесь крупномасштабными развертываниями, у вас обычно есть свой собственный репозиторий пакетов, поэтому еще одна проблема не слишком важна. Просто недостаточно сделать для него хороший пакет.

Тем не менее, я работал над созданием такого пакета. Я «работаю над этим» уже два года, хотя сейчас мне это нужно. Надеюсь, скоро будет PPA. :-) Если вы уже делали упаковку .deb и знаете внутренности JBoss, возможно, мы можем сотрудничать.

Попытавшись сам пакет jboss, я уверен, что знаю, почему для него нет хорошего пакета.

1. Требования к бизнесу. Это продукт «предприятия-иш» RedHat. Ubuntu - дистрибутив Debian-esque. Таким образом, не многие люди используют его на Ubuntu или Debian, потому что большинство людей, которые хотят иметь «корпоративный» бит, также хотят, чтобы корпоративная поддержка, и подумайте, что лучше всего пойти RedHat.
2. Stricter требования. Вы взглянули на пакет tomcat? Это беспорядок. По всему месту. Распространение tarcat tarball (и пакет RedHat, если на то пошло) помещает все в / usr / share, последний раз я проверил, что было пару лет назад. Напротив, пакеты Debian / Ubuntu имеют переменные данные в / var / lib / tomcat * (CATALINA_HOME), статические java-библиотеки в / usr / share / tomcat * (TOMCAT_HOME), JNI в / usr / lib / tomcat *, и используйте символические ссылки, чтобы связать все это вместе. Это связано с тем, что пакет Debian предназначен для установки одной установки tomcat для работы с несколькими экземплярами tomcat, а также потому, что требования к упаковке более строгие для Debian / Ubuntu и на самом деле настаивают на том, что конфигурация находится в / etc, переменные данные находятся в / var и т. д. RedHat не имеет таких требований, и дистрибутив JBoss скорее объединяет все вместе так, как это трудно вынести.
3. Перфекционизм перед лицом плохой / несуществующей документации. Если вы посмотрите на пакеты Debian / Ubuntu для libjboss- *, вы увидите, что все библиотеки являются отдельными пакетами. Это потому, что они на самом деле не один продукт, а их коллекция, которые просто работают вместе. В стандартном архиве JBoss у вас есть «по умолчанию» и «все» (и «минимальные», я думаю ...), которые представляют собой несколько «примерных» комбинаций ... но на самом деле возможны многие комбинации. Я уверен, что упаковщик знает об этом и пытается установить только те библиотеки, которые вам нужны в системе JBoss, как хорошая практика (но почти никогда не соблюдалась, в случае JBoss, где почти каждый просто использует пример «все»).
4. Сложность интеграции. Нет сценариев запуска службы, которые находятся где-то рядом с уровнем сложности, который является нормальным в Ubuntu. Сам процесс сервера просто плюется на stdout, даже. Вам нужно будет найти способы перенаправления на файлы журналов с возможностью поворота, настроить cron / logwatch, чтобы справиться с ним, написать сценарий инициализации и т. Д. Это не тривиально, особенно учитывая, что JBoss - это коллекция «любых» библиотек, которые пользователь решает использовать, и not , разработанных с учетом системных установок, - это, безусловно, «запуск этого из вашего домашнего каталога» типа установки из коробки.
5. Отсутствие необходимости. Tarball, помещенный в / opt, возможно, с checkinstall , выполняет работу для тех, кто действительно осуществляет широкомасштабные развертывания. Если вы занимаетесь крупномасштабными развертываниями, у вас обычно есть свой собственный репозиторий пакетов, поэтому еще одна проблема не слишком важна. Просто недостаточно сделать для него хороший пакет.

Тем не менее, я работал над созданием такого пакета. Я «работаю над этим» уже два года, хотя сейчас мне это нужно. Надеюсь, скоро будет PPA. :-) Если вы уже делали упаковку .deb и знаете внутренности JBoss, возможно, мы можем сотрудничать.

Попытавшись сам пакет jboss, я уверен, что знаю, почему для него нет хорошего пакета.

1. Требования к бизнесу. Это продукт «предприятия-иш» RedHat. Ubuntu - дистрибутив Debian-esque. Таким образом, не многие люди используют его на Ubuntu или Debian, потому что большинство людей, которые хотят иметь «корпоративный» бит, также хотят, чтобы корпоративная поддержка, и подумайте, что лучше всего пойти RedHat.
2. Stricter требования. Вы взглянули на пакет tomcat? Это беспорядок. По всему месту. Распространение tarcat tarball (и пакет RedHat, если на то пошло) помещает все в / usr / share, последний раз я проверил, что было пару лет назад. Напротив, пакеты Debian / Ubuntu имеют переменные данные в / var / lib / tomcat * (CATALINA_HOME), статические java-библиотеки в / usr / share / tomcat * (TOMCAT_HOME), JNI в / usr / lib / tomcat *, и используйте символические ссылки, чтобы связать все это вместе. Это связано с тем, что пакет Debian предназначен для установки одной установки tomcat для работы с несколькими экземплярами tomcat, а также потому, что требования к упаковке более строгие для Debian / Ubuntu и на самом деле настаивают на том, что конфигурация находится в / etc, переменные данные находятся в / var и т. д. RedHat не имеет таких требований, и дистрибутив JBoss скорее объединяет все вместе так, как это трудно вынести.
3. Перфекционизм перед лицом плохой / несуществующей документации. Если вы посмотрите на пакеты Debian / Ubuntu для libjboss- *, вы увидите, что все библиотеки являются отдельными пакетами. Это потому, что они на самом деле не один продукт, а их коллекция, которые просто работают вместе. В стандартном архиве JBoss у вас есть «по умолчанию» и «все» (и «минимальные», я думаю ...), которые представляют собой несколько «примерных» комбинаций ... но на самом деле возможны многие комбинации. Я уверен, что упаковщик знает об этом и пытается установить только те библиотеки, которые вам нужны в системе JBoss, как хорошая практика (но почти никогда не соблюдалась, в случае JBoss, где почти каждый просто использует пример «все»).
4. Сложность интеграции. Нет сценариев запуска службы, которые находятся где-то рядом с уровнем сложности, который является нормальным в Ubuntu. Сам процесс сервера просто плюется на stdout, даже. Вам нужно будет найти способы перенаправления на файлы журналов с возможностью поворота, настроить cron / logwatch, чтобы справиться с ним, написать сценарий инициализации и т. Д. Это не тривиально, особенно учитывая, что JBoss - это коллекция «любых» библиотек, которые пользователь решает использовать, и not , разработанных с учетом системных установок, - это, безусловно, «запуск этого из вашего домашнего каталога» типа установки из коробки.
5. Отсутствие необходимости. Tarball, помещенный в / opt, возможно, с checkinstall , выполняет работу для тех, кто действительно осуществляет широкомасштабные развертывания. Если вы занимаетесь крупномасштабными развертываниями, у вас обычно есть свой собственный репозиторий пакетов, поэтому еще одна проблема не слишком важна. Просто недостаточно сделать для него хороший пакет.

Тем не менее, я работал над созданием такого пакета. Я «работаю над этим» уже два года, хотя сейчас мне это нужно. Надеюсь, скоро будет PPA. :-) Если вы уже делали упаковку .deb и знаете внутренности JBoss, возможно, мы можем сотрудничать.

Попытавшись сам пакет jboss, я уверен, что знаю, почему для него нет хорошего пакета.

1. Требования к бизнесу. Это продукт «предприятия-иш» RedHat. Ubuntu - дистрибутив Debian-esque. Таким образом, не многие люди используют его на Ubuntu или Debian, потому что большинство людей, которые хотят иметь «корпоративный» бит, также хотят, чтобы корпоративная поддержка, и подумайте, что лучше всего пойти RedHat.
2. Stricter требования. Вы взглянули на пакет tomcat? Это беспорядок. По всему месту. Распространение tarcat tarball (и пакет RedHat, если на то пошло) помещает все в / usr / share, последний раз я проверил, что было пару лет назад. Напротив, пакеты Debian / Ubuntu имеют переменные данные в / var / lib / tomcat * (CATALINA_HOME), статические java-библиотеки в / usr / share / tomcat * (TOMCAT_HOME), JNI в / usr / lib / tomcat *, и используйте символические ссылки, чтобы связать все это вместе. Это связано с тем, что пакет Debian предназначен для установки одной установки tomcat для работы с несколькими экземплярами tomcat, а также потому, что требования к упаковке более строгие для Debian / Ubuntu и на самом деле настаивают на том, что конфигурация находится в / etc, переменные данные находятся в / var и т. д. RedHat не имеет таких требований, и дистрибутив JBoss скорее объединяет все вместе так, как это трудно вынести.
3. Перфекционизм перед лицом плохой / несуществующей документации. Если вы посмотрите на пакеты Debian / Ubuntu для libjboss- *, вы увидите, что все библиотеки являются отдельными пакетами. Это потому, что они на самом деле не один продукт, а их коллекция, которые просто работают вместе. В стандартном архиве JBoss у вас есть «по умолчанию» и «все» (и «минимальные», я думаю ...), которые представляют собой несколько «примерных» комбинаций ... но на самом деле возможны многие комбинации. Я уверен, что упаковщик знает об этом и пытается установить только те библиотеки, которые вам нужны в системе JBoss, как хорошая практика (но почти никогда не соблюдалась, в случае JBoss, где почти каждый просто использует пример «все»).
4. Сложность интеграции. Нет сценариев запуска службы, которые находятся где-то рядом с уровнем сложности, который является нормальным в Ubuntu. Сам процесс сервера просто плюется на stdout, даже. Вам нужно будет найти способы перенаправления на файлы журналов с возможностью поворота, настроить cron / logwatch, чтобы справиться с ним, написать сценарий инициализации и т. Д. Это не тривиально, особенно учитывая, что JBoss - это коллекция «любых» библиотек, которые пользователь решает использовать, и not , разработанных с учетом системных установок, - это, безусловно, «запуск этого из вашего домашнего каталога» типа установки из коробки.
5. Отсутствие необходимости. Tarball, помещенный в / opt, возможно, с checkinstall , выполняет работу для тех, кто действительно осуществляет широкомасштабные развертывания. Если вы занимаетесь крупномасштабными развертываниями, у вас обычно есть свой собственный репозиторий пакетов, поэтому еще одна проблема не слишком важна. Просто недостаточно сделать для него хороший пакет.

Тем не менее, я работал над созданием такого пакета. Я «работаю над этим» уже два года, хотя сейчас мне это нужно. Надеюсь, скоро будет PPA. :-) Если вы уже делали упаковку .deb и знаете внутренности JBoss, возможно, мы можем сотрудничать.