Cordiais saudações, pessoal do Guj.
Estou estudando Java há algum tempo e desde que comecei a me envolver com propostas de sistemas que, evidentemente, utilizam bancos de dados uma questão muito séria tem se instalado: durante o processo de instalação dos sistemas e seus bancos de dado como fica a questão de preparar o computador do usuário para que o nosso sistema fique totalmente operacional após sua instalação?
É uma questão que envolve o MySQL, no meu caso. Suponhamos que meu sistema esteja pronto e que ele use o banco de dados MySQL, mas no computador dos usuários não está instalado nem o MySQL nem o Java. Então, eu pergunto: Como devo proceder para instalar o banco de dados (MySQL) e o Java? Suponhamos que meu sistema vai funcionar baseado em um arquivo executavel com extensão jar, o que com muito esforço o pessoal do GUJ me ajudou a fazer. Mas e agora? Como eu instalo o Java, porque o jar precisa do Java para rodar; e que forma é mais conveniente para instalar o banco de dados?
Existe mais de um tipo de Instalação do MySQL que torna funcional o banco de dados? Existe uma estalação apenas de algum tipo de núcleo mais simples dos bancos de dados que torna funcional o sistema mas ocupa menos espaço e tem menos elementos do banco de dados?
Com relação a um banco de dados especifico do sistema, o arquivo de trabalho do nosso sistema e suas tabelas. Eu posso gerar o banco de dados e suas tabelas com comandos JDBA do Java?
Como vocês podem ver, minha cabeça esta cheia de duvidas quanto a tornar o sistema funcional com base em uma instalação feita por um arquivo de instalação, provavelmente um arquivo zipado com o Java, o banco de dados e o arquivo jar do sistema em questão.
Um grande abraço ao amigos do GUJ.
Atenciosamente,
Ronaldo
O nosso sistema é dessa maneira. Aqui a gente instala tudo manualmente. Instalamos o Java, depois o banco de dados (usamos PostgreSQL), depois o servidor/container web (hoje usamos o Wildfly, mas antes usámos o Tomcat. Ambos de versão bem específica porque tinha algumas coisas que só funcionavam corretamente com determinada versão) e depois as outras dependências.
Ou seja, tudo ainda muito manual. Já tentamos empacotar num daqueles softwares de Next, Next, Next pra automatizar, mas foi muito difícil pela questão de algumas coisas ainda serem muito manuais como ter que criar os bancos depois de instalado o SGBD, abrir o CLI do Wildfly pra dar deploy na aplicação Web.
Se for só .jar acho que só o Java e Banco de dados funciona. O .jar precisa estar bem criado porque pode ser que em produção não funcione porque as bibliotecas não foram incluídas na hora do build. E ter cuidado em criar o banco de dados com o mesmo nome que foi dado build na aplicação.
Sobre isso o pensamento do Sr. está correto.
1 curtida
Muito obrigado, Lucas. Faz dois anos que estudo Java e até agora não consegui nenhum cliente. Estou batalhando em cima da linguagem e aprendendo bastante mas preciso de um projeto real. Se você quiser montar uma equipe de desenvolvimento Java pode contar com este colaborador.
Hoje podemos ter equipes com membros distantes que o negócio funciona.
Abraço aos amigos do GUJ,
Ronaldo
Eu fazia diferente quando trabalhava com Java, usava o InnoSetup e empacotava tudo junto, JRE, Postgresql, a própria aplicação (convertia pra .exe usando o Launch4J)…
O meu .jar ficava bem grande, pq eu empacotava todas as libs dentro dele também, então exluía aquela pasta libs que ficava junto do build.
build.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- You may freely edit this file. See commented blocks below for -->
<!-- some examples of how to customize the build. -->
<!-- (If you delete it and reopen the project it will be recreated.) -->
<!-- By default, only the Clean and Build commands use this build script. -->
<!-- Commands such as Run, Debug, and Test only use this build script if -->
<!-- the Compile on Save feature is turned off for the project. -->
<!-- You can turn off the Compile on Save (or Deploy on Save) setting -->
<!-- in the project's Project Properties dialog box.-->
<project name="Imperium" default="default" basedir=".">
<description>Builds, tests, and runs the project Imperium.</description>
<import file="nbproject/build-impl.xml"/>
<!--
There exist several targets which are by default empty and which can be
used for execution of your tasks. These targets are usually executed
before and after some main targets. They are:
-pre-init: called before initialization of project properties
-post-init: called after initialization of project properties
-pre-compile: called before javac compilation
-post-compile: called after javac compilation
-pre-compile-single: called before javac compilation of single file
-post-compile-single: called after javac compilation of single file
-pre-compile-test: called before javac compilation of JUnit tests
-post-compile-test: called after javac compilation of JUnit tests
-pre-compile-test-single: called before javac compilation of single JUnit test
-post-compile-test-single: called after javac compilation of single JUunit test
-pre-jar: called before JAR building
-post-jar: called after JAR building
-post-clean: called after cleaning build products
(Targets beginning with '-' are not intended to be called on their own.)
Example of inserting an obfuscator after compilation could look like this:
<target name="-post-compile">
<obfuscate>
<fileset dir="${build.classes.dir}"/>
</obfuscate>
</target>
For list of available properties check the imported
nbproject/build-impl.xml file.
Another way to customize the build is by overriding existing main targets.
The targets of interest are:
-init-macrodef-javac: defines macro for javac compilation
-init-macrodef-junit: defines macro for junit execution
-init-macrodef-debug: defines macro for class debugging
-init-macrodef-java: defines macro for class execution
-do-jar: JAR building
run: execution of project
-javadoc-build: Javadoc generation
test-report: JUnit report generation
An example of overriding the target for project execution could look like this:
<target name="run" depends="Imperium-impl.jar">
<exec dir="bin" executable="launcher.exe">
<arg file="${dist.jar}"/>
</exec>
</target>
Notice that the overridden target depends on the jar target and not only on
the compile target as the regular run target does. Again, for a list of available
properties which you can use, check the target you are overriding in the
nbproject/build-impl.xml file.
-->
<target name="-post-jar">
<property name="store.jar.name" value="${application.title}"/>
<property name="store.dir" value="store"/>
<property name="store.jar" value="${store.dir}/${store.jar.name}.jar"/>
<echo message="Packaging ${store.jar.name} into a single JAR at ${store.jar}"/>
<delete dir="${store.dir}"/>
<mkdir dir="${store.dir}"/>
<jar destfile="${store.dir}/temp_final.jar" filesetmanifest="skip">
<zipgroupfileset dir="dist" includes="*.jar"/>
<zipgroupfileset dir="dist/lib" includes="*.jar"/>
<manifest>
<attribute name="Main-Class" value="${main.class}"/>
</manifest>
</jar>
<zip destfile="${store.jar}">
<zipfileset src="${store.dir}/temp_final.jar" excludes="META-INF/.SF, META-INF/.DSA, META-INF/*.RSA"/>
</zip>
<delete file="${store.dir}/temp_final.jar"/>
</target>
</project>
Infelizmente não tenho mais o script do innoSetup… Mas conseguia fazer bastante processo com ele, por exemplo:
- Verificava se na maquina existia o JRE, se não, instalava
- Verificava se existia o Postgresql, se não, instalava
- Rodava o script do banco pra gerar todas as tabelas.
- Adicionava os arquivos do projeto (.exe -.jar-, imagens, etc…)
- E por fim, criava uma cron que fazia backup do banco de dados regularmente e um que checava as possíveis atualizações (tudo isso local)
Como eu fazia tudo sozinho, esse processo todo me fez trocar o Java por algo Web, foi aí onde comecei a aprender ReactJS+Node, logo, o processo ficou muuuito mais fácil.
O InnoSetup tem muito material na internet, então vai ser tranquilo pra vc se achar. É bem tranquilo de usar
Inclusive automatizar esse processo é bem possível também, eu instalava ele minimizado, com as informações pré setadas.
Infelizmente vc não vai encontrar tudo de cara em uma pesquisa só, mas, que tem muito material sobre isso, tem sim
Se seu app não necessita de um banco de dados que receberá acessos simultâneo de usuários, é melhor fazer uso do Sqlite3 do que um mysql/mariadb/postgresql, justamente por conta dessa configuração inicial ser mais “enjoada”.de fazer.
Quanto ao JRE, vc consegue com essas ferramentas, como a citada pelo @rodriguesabner, deixá-la em uma subpasta do seu app, e quando seu app for iniciado, essa JRE que será usada. O mesmo pode ser feito com bibliotecas adicionais, deixar fora do JAR do seu app, e assim ele não ficar grande e pesado para abrir, pois terá que extrair tudo, sempre que for iniciado.
2 curtidas
No passado, para sistemas desktop com banco de dados eu criava instaladores para o Windows utilizando o Ghost Installer.
Nesse instalador eu embutia o JRE, os jars da aplicação e os arquivos do banco de dados.
Certo, Staroski. E com o seu procedimento você já instalava o seu sistema e o banco de dados completo? Outras perguntas, o Ghost Installer é gratuito? Ele (Ghost Installer) cria icones no menu windows automaticamente?
Aparentemente essa ferramenta parou de ser desenvolvida, mas ainda se encontra dowloads dela por aí.
Sim
Eu usava a versão gratuita onde toda a configuração era feita por arquivos XML, mas ele tinha uma versão paga com um editor visual.
Nada é automático, você tinha que configurar o XML do instalador pra isso.
1 curtida