[Java + Eclipse] Exporteren naar JAR met externe JAR's

[Verwijderd]

Hallo iedereen,

Ik heb een klein programma geschreven om een heleboel loongegevens te verwerken en weg te schrijven naar Excel files.
Ik heb hiervoor nogal wat externe JAR's gebruikt die de Excel mooi voor mij afhandelden.
Wanneer ik in Eclipse de heleboel uitvoer werkt alles naar wens (na het toevoegen van de JAR's aan het Build Path.

Nu wil ik echter alles exporteren naar een mooi uitvoerbaar formaat!

Allereerst heb ik geprobeerd Eclipse alles te laten exporteren naar een JAR file, volledig automatisch, het Manifest zelf laten genereren.
Op het eerste zicht werkte het, maar ik kreeg een ClassNotFound exception bij de eerste beste klasse uit een externe JAR.

Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: au/com/by
tecode/opencsv/CSVReader

Ik heb hierna geprobeerd zelf een Manifest te schrijven, met volgende zaken erin:

code:

Class-Path: commons-beanutils.jar
 commons-beanutils-bean-collections.jar
 commons-beanutils-core.jar
 commons-collections-3.2.1.jar
 commons-collections-3.2.1-javadoc.jar
 commons-collections-3.2.1-sources.jar
 commons-collections-testframework-3.2.1.jar
 commons-digester-1.8.jar
 commons-jexl-1.1.jar
 commons-logging-1.1.jar
 junit-3.8.1.jar
 jxls-core-0.9.6.jar
 jxls-reader-0.9.6.jar
 log4j-1.2.13.jar lib/opencsv-1.8.jar
 poi-3.0.1-FINAL-20080204.jar
 poj-contrib-3.0.1-FINAL-20080204.jar
 poi-scratchpad-3.0.2-FINAL-20080204.jar

nog steeds zonder succes.

En ja, al deze jar's staan in dezelfde map als mijn geexporteerde JAR bij het uitvoeren ervan!

Mijn vraag nu: Wat doe ik verkeerd? Is er misschien een andere manier dan een JAR om de hele boel te exporteren?


Bedankt!


Bart

[qanar]

externe jar's extracten en zijn class files mee invoegen in jouw jar.

[Standeman]

^^ lijkt me een slecht idee.. Leuk als je een keer een nieuwe versie krijgt van je 3rd party software!

Kijk even in je manifest of daar de jar's wel genoemd worden in het classpath. Oeps, iets te snel door gescrolld.

Volgens mij moeten de jars space delimited zijn.

Verder: de tutorial

[ Voor 35% gewijzigd door Standeman op 09-07-2008 13:02 ]

[Apache]

Staan je jars wel effectief mee in de directory waar je jou .jar hebt staan?

Evt kan je een .bat file aanmaken met een java -jar jouw.jar -cp opsomming.van.jars.jar om het snel te laten starten.

[sjongenelen]

Standeman schreef op woensdag 09 juli 2008 @ 12:56:

Volgens mij moeten de jars space delimited zijn.

volgens mij ook, en ná de laatste jar MOET een enter..!

[Verwijderd]

ik heb het volgende geprobeerd:

java -jar MyJar.jar -cp commons-beanutils.jar commons-beanutils-bean-collections.jar commons-beanutils-core.jar commons-collections-3.2.1.jar commons-collections-3.2.1-javadoc.jar commons-collections-3.2.1-sources.jar commons-collections-testframework-3.2.1.jar commons-digester-1.8.jar commons-jexl-1.1.jar commons-logging-1.1.jar junit-3.8.1.jar jxls-core-0.9.6.jar jxls-reader-0.9.6.jar log4j-1.2.13.jar lib/opencsv-1.8.jar poi-3.0.1-FINAL-20080204.jar poj-contrib-3.0.1-FINAL-20080204.jar poi-scratchpad-3.0.2-FINAL-20080204.jar

ook met nog steeds deze error

Om op Standeman te antwoorden:
Alle JAR's zijn space-delimited, met witregel erna

[Verwijderd]

UPDATE:

met veel gesukkel heb ik manueel de .class files van de externe JAR's toegevoegd in mijn JAR, hetgeen werkt!

Toch nog blijven proberen om die andere JAR's extern te houden!

[Standeman]

Verwijderd schreef op woensdag 09 juli 2008 @ 13:10:
ik heb het volgende geprobeerd:

[...]

ook met nog steeds deze error

Om op Standeman te antwoorden:
Alle JAR's zijn space-delimited, met witregel erna

Als je het via de command-line doet (met -cp dus), moet er wel ; als delimiter tussen zetten, dus

java -jar foo.jar -cp bar.jar;bla.jar

Overigens vermoed ik dat deze jar niet bestaat:

java -jar MyJar.jar -cp commons-beanutils.jar commons-beanutils-bean-collections.jar commons-beanutils-core.jar commons-collections-3.2.1.jar commons-collections-3.2.1-javadoc.jar commons-collections-3.2.1-sources.jar commons-collections-testframework-3.2.1.jar commons-digester-1.8.jar commons-jexl-1.1.jar commons-logging-1.1.jar junit-3.8.1.jar jxls-core-0.9.6.jar jxls-reader-0.9.6.jar log4j-1.2.13.jar lib/opencsv-1.8.jar poi-3.0.1-FINAL-20080204.jar poj-contrib-3.0.1-FINAL-20080204.jar poi-scratchpad-3.0.2-FINAL-20080204.jar

Wel opletten he..

(Alle classfiles bij elkaar gooien is gewoon geen oplossing)

[ Voor 3% gewijzigd door Standeman op 09-07-2008 14:51 ]

[PV85]

Waarom is dat geen oplossing? Soms wil je dat toch?
Waarom zou ik los me libs meeleveren zodat andere mensen er mee kunnen klooien? Als ik die libs wil updaten dan doe ik dat wel in de volgende release.
Vaak moet je echter libs wel los meeleveren ivm licenties, dan heb je wil een punt. Maar soms ook niet en dan lever ik me programma liever uit als 1 grote jar.

Trouwens der is een handige plugin voor eclipse die dat voor je doet: FatJar.

[ Voor 10% gewijzigd door PV85 op 09-07-2008 15:00 ]

[Standeman]

Omdat je vaak bestaande releases wil updaten i.v.m. bugfixes in de 3rd party software. Het leveren van patches wordt dan een enorm gedoe.Verder kan je ook lastig zien welke 3rd party software je applicatie allemaal gebruikt.

Het werkt allemaal wel en wanneer je software op maar een paar plaatsen draait is het ook nog wel beheersbaar. Zodra je je software distribueert naar tientallen klanten en het aantal jar's flink stijgt begint het allemaal al wat lastiger te worden.

Waarom bij elke release al dat handmatige werk gaan doen, terwijl het prima automatisch kan? Waarom zal je het jezelf (en anderen) verkeerd aanleren zodat je bij groeiende projecten dik in de problemen komt?
Niet echt dat de manifest of het opgeven van een classpath rocket-science is. Het heeft alleen maar voordelen! Het is imo net zoiets als je hele app in 1 grote class file prakken. Het werkt, maar zodra het allemaal wat complexer wordt, kom je er nooit meer uit.

[ Voor 10% gewijzigd door Standeman op 09-07-2008 15:46 ]

[Robtimus]

Uit de TS:

lib/opencsv-1.8.jar

Dit is de enige met lib ervoor, en ik weet dat CSVReader in deze JAR zit. Volgens mij heb je in je eerste poging gewoon 1x lib/ laten staan, en gaat het goed als je dat fixt.

[Janoz]

Regels in de metainf mogen niet langer dan 70 tekens zijn en verschillende jars moeten alleen met spaties gescheiden worden. Dat betekend dat de namen ook halverwege afgebroken kunnen worden. Verder moet je ook de nieuwe regel met een spatie laten beginnen om aan te geven dat je nog steeds bezig bent met je classpath. Ikzelf laat het classpath in mijn meta inf gewoon genereren door ant. Voorbeeld van mijn episodebutler manifest:

code:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0
Created-By: 1.5.0_11-b03 (Sun Microsystems Inc.)
Main-Class: com.janoz.eb.Core
Version: 0.6.037
Class-Path: /lib lib/picohttpd-0.1.001.jar lib/janoz-utils-0.1.001-EB.
 jar lib/opencsv-1.7.jar lib/hsqldb.jar lib/commons-logging-1.1.jar li
 b/commons-httpclient-3.0.1.jar lib/commons-codec-1.3.jar

Nu ik er zo naar kijk vraag ik me eigenlijk af waar die /lib vandaan komt, maar ik zie dat dat nog verdwaald in mijn ant staat./ Misschien moet ik dat maar eens een keertje aanpakken..

Relevante stukjes ant:

Hier de classpath definitie:

code:

    <path id="classpath">
        <pathelement location="${lib.dir}/picohttpd-0.1.001.jar"/>
        <pathelement location="${lib.dir}/janoz-utils-0.1.002-EB.jar"/>
        <pathelement location="${lib.dir}/opencsv-1.7.jar"/>
        <pathelement location="${lib.dir}/hsqldb.jar"/>
        <pathelement location="${lib.dir}/commons-logging-1.1.jar"/>
        <pathelement location="${lib.dir}/commons-httpclient-3.0.1.jar"/>
        <pathelement location="${lib.dir}/commons-codec-1.3.jar"/>
    </path>

Vervolgens baterij ik het om naar een manifest classpath (dummy is volgens mij omdat jar verplicht is, maar wordt genegeerd)

code:

    <manifestclasspath property="jar.classpath" jarfile="dummy.jar" >
        <classpath refid="classpath" />
    </manifestclasspath>

En tot slot het stuk waarin uiteindelijk de jar gemaakt wordt:

code:

        <jar destfile="${build_app.dir}/${ant.project.name}.jar" basedir="${build_classes.dir}">
            <manifest>
                <attribute name="Main-Class" value="com.janoz.eb.Core"/>
                <attribute name="Class-Path" value="/lib ${jar.classpath}"/>
                <attribute name="Version" value="${version}"/>
            </manifest>
            <zipfileset prefix="data/web" dir="${gfx.dir}">
                <include name="style.css"/>
                <include name="episodebutler.gif"/>
                <include name="episodebutler.ico"/>
                <include name="feed.gif"/>
            </zipfileset>
            <zipfileset prefix="data/web" dir="${tmp.dir}">
                <include name="javascript.js"/>
            </zipfileset>
            <zipfileset prefix="data" dir="${app.dir}">
                <include name="configuration.properties"/>
            </zipfileset>
        </jar>

In het laatste stuk zie ik nu ineens ook waar de /lib vandaan komt ..

[PV85]

Janoz schreef op woensdag 09 juli 2008 @ 22:39:
Regels in de metainf mogen niet langer dan 70 tekens zijn en verschillende jars moeten alleen met spaties gescheiden worden. Dat betekend dat de namen ook halverwege afgebroken kunnen worden. Verder moet je ook de nieuwe regel met een spatie laten beginnen om aan te geven dat je nog steeds bezig bent met je classpath. Ikzelf laat het classpath in mijn meta inf gewoon genereren door ant. Voorbeeld van mijn episodebutler manifest:

code:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0
Created-By: 1.5.0_11-b03 (Sun Microsystems Inc.)
Main-Class: com.janoz.eb.Core
Version: 0.6.037
Class-Path: /lib lib/picohttpd-0.1.001.jar lib/janoz-utils-0.1.001-EB.
 jar lib/opencsv-1.7.jar lib/hsqldb.jar lib/commons-logging-1.1.jar li
 b/commons-httpclient-3.0.1.jar lib/commons-codec-1.3.jar

Nu ik er zo naar kijk vraag ik me eigenlijk af waar die /lib vandaan komt, maar ik zie dat dat nog verdwaald in mijn ant staat./ Misschien moet ik dat maar eens een keertje aanpakken..

Relevante stukjes ant:

Hier de classpath definitie:

code:

    <path id="classpath">
        <pathelement location="${lib.dir}/picohttpd-0.1.001.jar"/>
        <pathelement location="${lib.dir}/janoz-utils-0.1.002-EB.jar"/>
        <pathelement location="${lib.dir}/opencsv-1.7.jar"/>
        <pathelement location="${lib.dir}/hsqldb.jar"/>
        <pathelement location="${lib.dir}/commons-logging-1.1.jar"/>
        <pathelement location="${lib.dir}/commons-httpclient-3.0.1.jar"/>
        <pathelement location="${lib.dir}/commons-codec-1.3.jar"/>
    </path>

Vervolgens baterij ik het om naar een manifest classpath (dummy is volgens mij omdat jar verplicht is, maar wordt genegeerd)

code:

    <manifestclasspath property="jar.classpath" jarfile="dummy.jar" >
        <classpath refid="classpath" />
    </manifestclasspath>

En tot slot het stuk waarin uiteindelijk de jar gemaakt wordt:

code:

        <jar destfile="${build_app.dir}/${ant.project.name}.jar" basedir="${build_classes.dir}">
            <manifest>
                <attribute name="Main-Class" value="com.janoz.eb.Core"/>
                <attribute name="Class-Path" value="/lib ${jar.classpath}"/>
                <attribute name="Version" value="${version}"/>
            </manifest>
            <zipfileset prefix="data/web" dir="${gfx.dir}">
                <include name="style.css"/>
                <include name="episodebutler.gif"/>
                <include name="episodebutler.ico"/>
                <include name="feed.gif"/>
            </zipfileset>
            <zipfileset prefix="data/web" dir="${tmp.dir}">
                <include name="javascript.js"/>
            </zipfileset>
            <zipfileset prefix="data" dir="${app.dir}">
                <include name="configuration.properties"/>
            </zipfileset>
        </jar>

In het laatste stuk zie ik nu ineens ook waar de /lib vandaan komt ..

Fat Jar Eclipse Plug-In

The Fat Jar Eclipse Plug-In is a Deployment-Tool which deploys an Eclipse java-project into one executable jar.

It adds the Entry "Build Fat-JAR" to the Export-Wizard.
In addition to the eclipse standard jar-exporter referenced classes and jars are included to the "Fat-Jar", so the resulting jar contains all needed classes and can be executed directly with "java -jar", no classpath has to be set, no additional jars have to be deployed.

Jars, External-Jars, User-Libraries, System-Libraries, Classes-Folders and Project-Exports are considered by the plugin.
The Main-Class can be selected and Manifest-files are merged.
The One-JAR option integrates a specialised Class-Loader written by Simon Tuffs ( http://one-jar.sourceforge.net/ ) which handles jar-files inside a jar.
Individual files and folders can be excluded or added to the jar.
Different settings can be stored and re-executed as "Quick Build" via the context-menu.

Doet dit geloof ik allemaal voor je met een paar klikken. Niet dat het niet nuttig is om dit op deze manier te leren.

[ Voor 14% gewijzigd door PV85 op 09-07-2008 23:48 ]

[Verwijderd]

PV85 schreef op woensdag 09 juli 2008 @ 23:40:
[...]


Fat Jar Eclipse Plug-In


[...]


Doet dit geloof ik allemaal voor je met een paar klikken. Niet dat het niet nuttig is om dit op deze manier te leren.

werkt inderdaad perfect!
Voorlopig kan ik het zo voorleggen als beta.
Toch is het niet meer dan een kleine fout volgens mij. Ik ga blijven zoeken

Bedankt GoT

[Janoz]

PV85 schreef op woensdag 09 juli 2008 @ 23:40:
[...]


Fat Jar Eclipse Plug-In


[...]


Doet dit geloof ik allemaal voor je met een paar klikken. Niet dat het niet nuttig is om dit op deze manier te leren.

Ik ga er zeker eens naar kijken, maar ik denk niet dat ik snel van een antscript af ga stappen voor het maken van de distributables. Het maken van de jars is lang niet de enige actie die ik uithaal.