[Java] Executeble jar en lib map in één

[Verwijderd]

Is er een mogelijkheid (in NetBeans) om de executable jar file en de dist map bij elkaar te voegen tot één uitvoerbaar bestand? Ik vind het namelijk erg lelijk dat je die losse lib folder altijd bij je jar file moet hebben.

[Confusion]

Alles in 1 file is iets dat je alleen voor de distributie wilt, maar iets dat verder alleen maar nadelen biedt. Het is daarom normaal dat applicaties uit diverse losse bestanden bestaan. Om het gemakkelijk installeerbaar te maken moet het in een van vele mogelijke archive formaten verpakken en er eventueel een installer bij schrijven. Installshield, executable zip, tgz met build en install scripts, .deb of .rpm, you name it.

[ Voor 9% gewijzigd door Confusion op 01-06-2008 17:46 ]

[Verwijderd]

Okee, ik zal eens kijken naar executable zip.

[Fuzzillogic]

Confusion schreef op zondag 01 juni 2008 @ 17:45:
Alles in 1 file is iets dat je alleen voor de distributie wilt, maar iets dat verder alleen maar nadelen biedt. Het is daarom normaal dat applicaties uit diverse losse bestanden bestaan. Om het gemakkelijk installeerbaar te maken moet het in een van vele mogelijke archive formaten verpakken en er eventueel een installer bij schrijven. Installshield, executable zip, tgz met build en install scripts, .deb of .rpm, you name it.

Nadeel daarvan is dat je het weer platformafhankelijk maakt, terwijl een jar in principe platformonafhankelijk is.

Eigenlijk zie ik het probleem van één jar niet zo. Het is vergelijkbaar met static linking. Als een library toch goed werkt voor jouw doel, dan kun je hem toch fijn embedden.

[Gerco]

Als je andere jar file wil embedden zou je gewoon je dependencies kunnen unzippen en de classes samen met je eigen classes in 1 jar stoppen. Dan heb je 1 grote jar file met alles erin en die kun je natuurlijk executable maken door het Main-Class attribuut in te stellen op je eigen main class.

Wat je ook kunt doen is de andere jars opnemen in je eigen jar (in een lib directory bijvoorbeeld) en dan een classloader schrijven die die jar files gebruikt om andere classes te laden. Dat is de aanpak die applicatie servers soms gebruiken om .war of .ear bestanden te kunnen draaien.

Een derde aanpak is dat je alles opneemt in die ene jarfile en bij het opstarten de dependencies uitpakt naar een temp directory. Dan start je daarna je echte applicatie met de uitgepakte jars op het classpath.

De eenvoudigste aanpak is zonder twijfel de eerste, al moet je daar wel opletten of je dependencies geen services registreren in hun META-INF/services en meer van dat soort jar-magie uithalen. Dat zul je dan natuurlijk in je eigen jar ook moeten doen.

[ Voor 13% gewijzigd door Gerco op 01-06-2008 19:01 ]

[Verwijderd]

Fuzzillogic schreef op zondag 01 juni 2008 @ 18:24:
[...]

Nadeel daarvan is dat je het weer platformafhankelijk maakt, terwijl een jar in principe platformonafhankelijk is.

Eigenlijk zie ik het probleem van één jar niet zo. Het is vergelijkbaar met static linking. Als een library toch goed werkt voor jouw doel, dan kun je hem toch fijn embedden.

Of dat kan hangt natuurlijk ook af van de licensing. Als je libs gebruikt die LGPL-released zijn, dan mag je niet zomaar embedden. Behalve als je eigen code ook LGPL is uiteraard.

Ook maakt het weinig uit dat je uiteindelijke distributie platform-afhankelijk is. Mensen zijn blijer als ze een exe/msi/deb/rpm/dmg-bestand kunnen dubbelklikken die automatisch een Java-omgeving verzorgt, en daarna de files installeert, dan als ze zelf Java moeten installeren, en daarna een kale jar-file moeten dubbelklikken om het programma te starten.

Als je daarnaast maar wel een tar.gz of een tar.bz2 beschikbaar stelt voor de mensen die aparte wensen hebben. In bedrijfsmatige Linux-systemen kan je bijvoorbeeld vaak geen package manager gebruiken, waardoor de deb en rpm afvallen. Een andere Unix-gebruiker zoals bijvoorbeeld een BSD-gebruiker heeft ook weinig aan de deb's en rpm's, en zal dus een van de archive-packages moeten pakken.

En je hebt vast ook Windows-gebruikers die de installer voor wat voor reden dan ook niet willen gebruiken, en tegelijkertijd WinZIP hebben in plaats van WinRAR, waardoor ze de tar niet kunnen openen. Die hebben dus een zip nodig.

[Verwijderd]

Bedankt voor de tips. Het gaat voor mij alleen op dit moment even te ver om ziets voor elkaar te krijgen. Ik vind het een beetje appart dat java het op deze manier doet. Persoonlijk zou ik het niet erg professioneel over vinden komen als iemand voor mij een programma heeft gemaakt die ik eerst moest uitpakken en er vervolgens van die losse jar filetjes bij zitten. Of is dit echt heel normaal in de programmeer wereld? Ik ben namelijk nog een beetje een beginner.

[Verwijderd]

In Eclipse heb je ook de Fat-Jar plugin.
Deze maakt het mogelijk je gehele project inclusief jar-dependecies in één jar te gieten door middel van enkele muisklikes.

Jammer genoeg heeft Netbeans hiervoor (voor zover ik weet) geen alternatief beschikbaar.

[LAN]

Het is heel normaal om een lib directorie bij je executale jar te hebben met daarin 3rd party libraries.
Het zijn gewoon losse componenten van andere partijen die jij nodig hebt om je programma te kunnen laten doen wat hij moet doen.
In de manifest file kun je dan de jars op de classpath zetten.

Je kunt het denk ik vergelijken met dll's die je bij je windows executable meelevert, zelfde principe.

[Bobco]

Verwijderd schreef op zondag 01 juni 2008 @ 20:22:
Bedankt voor de tips. Het gaat voor mij alleen op dit moment even te ver om ziets voor elkaar te krijgen. Ik vind het een beetje appart dat java het op deze manier doet. Persoonlijk zou ik het niet erg professioneel over vinden komen als iemand voor mij een programma heeft gemaakt die ik eerst moest uitpakken en er vervolgens van die losse jar filetjes bij zitten. Of is dit echt heel normaal in de programmeer wereld? Ik ben namelijk nog een beetje een beginner.

Het is heel gebruikelijk om het op deze manier te doen. Het laat aan degene die de software installeert ook de nodige vrijheid om bepaalde libs bijvoorbeeld te vervangen door een nieuwere versie als dat nodig is. Sommige grotere Java open source applicaties bieden twee verschillende distributies aan: één met alle libraries en één zonder.

Als iemand toch al alle libraries heeft staan is het niet nodig om nog een keer alles te installeren. Bij dit soort applicaties wordt er over het algemeen vanuit gegaan dat degene die de applicatie installeert/draait weet wat hij doet. Dit is wellicht een wat ander publiek dan een 'echte' eindgebruiker.

De manier waarop Java met libraries omgaat heeft voor- en nadelen. Voordeel is dat het allemaal heel flexibel is, nadeel dat je alles precies goed moet hebben staan, anders werkt het echt niet.

[Janoz]

Verwijderd schreef op zondag 01 juni 2008 @ 20:22:
Bedankt voor de tips. Het gaat voor mij alleen op dit moment even te ver om ziets voor elkaar te krijgen. Ik vind het een beetje appart dat java het op deze manier doet. Persoonlijk zou ik het niet erg professioneel over vinden komen als iemand voor mij een programma heeft gemaakt die ik eerst moest uitpakken en er vervolgens van die losse jar filetjes bij zitten. Of is dit echt heel normaal in de programmeer wereld? Ik ben namelijk nog een beetje een beginner.

Zo vreemd is dat helemaal niet en het is ook niet beperkt tot java alleen. Ook andere distributies hebben vaak een stapel dll files erbij.

Als je proffesioneel over wilt komen maak je een installer. Dat werkt iig een stuk beter dan een executable zip file. (Voor de platform onafhankelijkheid kun je vervolgens verschillende installers maken, maar zolang je ook de kale java versie in een zip aanbied lijkt me dat ook wel redelijk afgedekt.)