Как правильно упаковать установщик JRE в мой установщик? - PullRequest
2 голосов
/ 07 ноября 2008

У меня есть приложение Java, для которого я пишу установщик. Мы используем программу AdvancedInstaller для создания нашего установщика (ну, в настоящий момент мы оцениваем его, но скоро обязательно приобретем лицензию), и, хотя он имеет специальную поддержку для приложений Java, он больше ориентирован на их переупаковку в настольный компьютер. типа приложений, а наше программное обеспечение представляет собой серию Java-сервисов и других утилит, которые не имеет смысла распространять в EXE-оболочках. Целевая аудитория этого программного обеспечения очень специфична, и мы знаем, что наше программное обеспечение, вероятно, будет автоматически распространяться на компьютерах под управлением Windows 2003 Server. Поэтому требование Java в качестве предварительного условия в основном делает больше работы для какого-то плохого системного администратора, и я бы предпочел этого избежать, если это вообще возможно, переупаковав установщик JRE внутри нашей собственной.

Я обнаружил, что, если я попытался запустить установщик JRE в качестве шага предварительной установки из моего MSI, он жалуется, что другой установщик уже запущен (мой, конечно), поэтому он выручает. Когда я пытаюсь добавить установщик JRE в качестве предварительного программного обеспечения в проекте AdvancedInstaller (в виде EXE-файла в комплекте, а не URL-ссылки), на самом деле он никогда не устанавливается, несмотря на попытки принудительной установки.

Какой лучший способ упаковать JRE? Я не очень-то разбираюсь в Java, поэтому я не слишком много знаю о том, как другие разработчики справляются с этой же проблемой, за исключением того, что их пользователи должны самостоятельно искать и устанавливать JRE. Идеальным решением для нас было бы найти установщик EXE, который можно запустить из другого установщика MSI, или, если это возможно, просто упаковать все файлы внутри JRE, а затем создать соответствующие переменные реестра и среды. Как мне это сделать?

Ответы [ 3 ]

4 голосов
/ 07 ноября 2008

Я не знаю, является ли это «способом» сделать это, но столкнувшись с несколько схожей проблемой, мы просто заархивируем установленную JRE с остальными файлами нашего приложения и убедимся, что наши стартовые скрипты используют не java ..., а ..\..\jre\bin\java ... или аналогичные. JRE распаковывается как часть нашего процесса установки в подкаталоге, где мы устанавливаем, и все.

2 голосов
/ 07 ноября 2008

Я согласен с ответом bdumitriu :

достаточно простого почтового индекса jre, если вы не хотите связать этот jre с:

  • java по умолчанию (это означает, что вы должны добавить java.exe распакованного jre к пути перед любыми другими ссылками на java пути)
  • Java по умолчанию для некоторого скрипта (вы можете определить JAVA_HOME как ссылку на вашу новую разархивированную jre, но это может иметь побочные эффекты на другом скрипте, также использующем JAVA_HOME до этой новой JRE)
  • файловые ассоциации, такие как файлы .jnlp или .jar (для этого требуется изменение реестра )
  • регистрация java-плагина для браузера (требуется также изменение реестра)

Если последние два пункта вас не интересуют на рабочем столе, связанном с этим депиляцией, достаточно простого zip-а.

1 голос
/ 29 мая 2013

http://www.syswow64.co.uk/2013/05/java-7-update-21-1721-enterprise.html

Проблема во многих блогах и статьях связана с созданием файлов «deploy.config» и «deploy.properties» для развертывания на предприятии. В моем случае я хотел установить уровень безопасности «Средний», но каждый раз, когда я открывал панель управления Java, для нее устанавливалось значение по умолчанию HIGH.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...