Пакетная справка Java - PullRequest
0 голосов
/ 30 марта 2011

Моя компания пытается определить лучшую стратегию для реализации пакетных программ Java. У нас есть несколько сотен (и растущих) отдельных программ на Java. Большинство из них являются отдельными Jasper Reports, но некоторые являются большими пакетными заданиями Java. В настоящее время каждый Java-проект упакован в независимый JAR-файл с использованием опции экспорта Eclipse. Эти JAR-файлы затем внедряются на наш сервер Linux вручную, где они тестируются. Если они проходят тестирование, они затем переносятся через QA и на Production через домашнюю систему контроля исходного кода.

Это лучшая стратегия для пакетной Java? Текущее обслуживание может быть хлопотным, поскольку поиск файлов Jar не легок, и разные разработчики создают новые Java-проекты (новые отчеты) каждую неделю.

Импорт существующих проектов из файлов Jar в Eclipse также является сложным процессом. Нам бы хотелось, чтобы все было проще. Мы подумали об упаковке всего кода в один большой проект и написании интерфейса для выполнения желаемого «пакета» (или программы), возможно, с использованием веб-сервера.

Что другие люди / компании делают со своими пакетными Java-программами? Есть ли на этом материале лучшие практики? Любая помощь / идеи / рабочие модели будут оценены.

Ответы [ 2 ]

2 голосов
/ 30 марта 2011

Я бы сказал, что вы должны иметь возможность создавать одно веб-приложение для доступа к отчетам Jasper, а не кучу пакетных процессов. Затем, когда вам нужно развернуть новый отчет, просто разверните незначительное обновление, которое обращается к новому скомпилированному файлу отчета Jasper.

Тем не менее, вы должны проверять свой код, а не двоичные файлы, в хранилище Subversion или Git. Дамп «доморощенного» репозитория исходного кода. Жизнь слишком коротка, чтобы пытаться выращивать подобные вещи. Просто используйте Git или Subversion, они проверенные, простые и функциональные. Когда вы импортируете новый проект, просто извлеките его из Subversion, не пытайтесь импортировать файл JAR из вашей Eclipse IDE.

Поместите ваши JAR-файлы в репозиторий Maven, например Nexus, и разверните их в QA и Production. Создавайте автоматические сборки для каждого проекта (будь то с Maven или что-то еще). Не полагайтесь на IDE для экспорта файлов JAR. Изменение и экспорт IDE из IDE предоставляет больше возможностей для человеческих ошибок. Кроме того, разные разработчики предпочтут разные IDE. Стандартизируя что-то вроде Maven, вы немного более независимы от IDE.

0 голосов
/ 30 марта 2011

Компания Mhy стандартизировала пакетное выполнение Java с использованием IBM Websphere Extended Deployment.

Здесь http://www.ibm.com/developerworks/websphere/techjournal/0801_vignola/0801_vignola.html - статья, рассказывающая о методах программирования и развертывания Java-пакета.

Введение в пакетное программирование с использованием WebSphere Extended Deployment Compute Grid Кристофер Виньола, WebSphere Архитектор, IBM

Обычно считается как устаревшая технология "мэйнфрейм", партия обработка показывает себя, чтобы быть почтенный стиль работы с ростом спрос на Java ™ и распределенный сред. Эта статья представляет захватывающая новая возможность для Java пакетная обработка от IBM®, лидер в системах пакетной обработки для последние 40 лет. Этот контент является частью Технический специалист по IBM WebSphere Developer Journal.

WebSphere Extended Deployment Compute рид предоставляет простую абстракцию шаг пакетной работы и его входы и выходы. Модель программирования краткий и простой в использовании. Встроенный контрольно-пропускной пункт / откат механизм облегчает сборку надежный, перезапускаемый пакет Java приложения.

Предоставлена ​​утилита Batch Simulator с этой статьей предлагает альтернативная среда тестирования, которая работает внутри вашего затмения (или Rational Разработчик приложений) разработка среда. Его генератор xJCL может помочь перейти к следующему этапу тестирования в модуле Compute Grid тестовый сервер.

Но даже если вы не заинтересованы в продукте, статью все равно необходимо прочитать.

...