Ik heb een toepassing geïnstalleerd, maar wanneer ik deze probeer uit te voeren (het is een uitvoerbare pot), gebeurt er niets. Als ik het vanaf de commandoregel uitvoer met:
java -jar “app.jar”
Ik krijg het volgende bericht:
geen hoofdmanifestkenmerk, in “app.jar”
Normaal gesproken, als ik het programma zelf had gemaakt, zou ik een hoofdklasse-attribuut aan het manifestbestand hebben toegevoegd. Maar in dit geval, aangezien het bestand uit een applicatie komt, kan ik dat niet doen. Ik heb ook geprobeerd de pot te extraheren om te zien of ik de hoofdklasse kon vinden, maar er zijn te veel klassen en geen van hen heeft het woord “main” in zijn naam. Er moet een manier zijn om dit op te lossen, want het programma werkt prima op andere systemen.
Antwoord 1, autoriteit 100%
Ten eerste is het raar om te zien dat je java -jar "app"
uitvoert en niet java -jar app.jar
Ten tweede, om een jar uitvoerbaar te maken… moet je een bestand met de naam META-INF/MANIFEST.MF gebruiken
het bestand zelf zou (minstens) deze ene voering moeten hebben:
Main-Class: com.mypackage.MyClass
Waarbij com.mypackage.MyClass
de klasse is die het public static void main(String[] args) ingangspunt bevat.
Merk op dat er verschillende manieren zijn om dit voor elkaar te krijgen met de CLI, Maven, Ant of Gradle:
Voor CLI is het volgende commando voldoende: (tks @dvvrt)
jar cmvf META-INF/MANIFEST.MF <new-jar-filename>.jar <files to include>
Voor Maven zou iets als het volgende fragment voldoende moeten zijn. Merk op dat dit alleen de plug-indefinitie is, niet de volledige pom.xml:
Laatste document over deze plug-in: zie https://maven.apache.org/ plugins/maven-jar-plugin/
<build>
<plugins>
<plugin>
<!-- Build an executable JAR -->
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.1.0</version>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<classpathPrefix>lib/</classpathPrefix>
<mainClass>com.mypackage.MyClass</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
</plugins>
</build>
(Kies een <version>
passend bij uw project.)
Voor Ant zou het onderstaande fragment moeten helpen:
<jar destfile="build/main/checksites.jar">
<fileset dir="build/main/classes"/>
<zipfileset includes="**/*.class" src="lib/main/some.jar"/>
<manifest>
<attribute name="Main-Class" value="com.acme.checksites.Main"/>
</manifest>
</jar>
Credits Michael Niemand –
Voor Gradle:
plugins {
id 'java'
}
jar {
manifest {
attributes(
'Main-Class': 'com.mypackage.MyClass'
)
}
}
Antwoord 2, autoriteit 29%
Dat had java -jar app.jar
moeten zijn in plaats van java -jar "app"
.
De optie -jar
werkt alleen als het JAR-bestand een uitvoerbaar JAR-bestand is, wat betekent dat het een manifestbestand moet hebben met een Main-Class
-attribuut erin. Zie Programma’s inpakken in JAR-bestanden om te leren hoe u een uitvoerbaar bestand maakt JAR.
Als het geen uitvoerbare JAR is, moet u het programma uitvoeren met zoiets als:
java -cp app.jar com.somepackage.SomeClass
waar com.somepackage.SomeClass
de klasse is die de main
methode bevat om het programma uit te voeren. (Wat die klasse is, hangt af van het programma, het is onmogelijk om te bepalen aan de hand van de informatie die je hebt verstrekt).
Antwoord 3, autoriteit 13%
Als alternatief kunt u maven-assembly-plugin gebruiken, zoals weergegeven in het onderstaande voorbeeld:
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<mainClass>com.package.MainClass</mainClass>
</manifest>
</archive>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
</plugin>
In dit voorbeeld worden alle afhankelijkheidsjars zoals gespecificeerd in de sectie automatisch opgenomen in uw enkele jar. Houd er rekening mee dat jar-met-afhankelijkheden letterlijk moeten worden geplaatst als, niet om te worden vervangen door de jar-bestandsnamen die u wilt opnemen.
Antwoord 4, autoriteit 6%
Dat komt omdat Java het Main-attribuut niet kan vinden in het MANIFEST.MF-bestand.
Het Main-attribuut is nodig om Java te vertellen welke klasse het moet gebruiken als het toegangspunt van de toepassing. In het jar-bestand bevindt het MANIFEST.MF-bestand zich in de map META-INF. Vraagt u zich af hoe u kunt kijken naar wat er in een jar-bestand staat? Open het jar-bestand met WinRAR.
Het hoofdattribuut in MANIFEST.MF ziet er als volgt uit:
Main-Class: <packagename>.<classname>
Je krijgt deze “no main manifest attribuut”-fout wanneer deze regel ontbreekt in het MANIFEST.MF-bestand.
Het is echt een enorme puinhoop om dit attribuut op te geven in het MANIFEST.MF-bestand.
Update: ik heb zojuist een heel nette manier gevonden om het toegangspunt van de toepassing in eclipse te specificeren.
Als je Export zegt,
Select Jar and next
[ give it a name in the next window ] and next
and next again
and you'll see " Select the class of the application entry point".
Just pick a class and Eclipse will automatically build a cool MANIFEST.MF for you.
Antwoord 5, autoriteit 4%
Ik had hetzelfde probleem. door de volgende regels aan het po-bestand toe te voegen, werkte het. De plug-in zorgt ervoor dat het bouwproces van uw applicatie met alle noodzakelijke stappen verloopt.
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
Antwoord 6, autoriteit 3%
Ik had dit probleem bij het maken van een jar met IntelliJ IDEA. Zie deze discussie.
Wat het voor mij oploste, was om het jar-artefact opnieuw te maken, door JAR > Van modules met afhankelijkheden te kiezen, maar de standaarddirectory voor META-INF/MANIFEST.MF niet te accepteren. Verander het van -/src/main/java in -/src/main/resources.
Anders nam het een manifest-bestand op in de jar, maar niet het bestand in -/src/main/java dat het zou moeten hebben.
Antwoord 7, autoriteit 3%
Voor maven is dit wat het heeft opgelost (voor mij, voor een Veetle-codebase op GitHub):
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.0</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<transformers>
<transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<mainClass>org.lazydevs.veetle.api.VeetleAPI</mainClass>
</transformer>
</transformers>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Proost…
Antwoord 8, autoriteit 3%
Het Gradle-antwoord is om een jar/manifest/attributen-instelling als volgt toe te voegen:
apply plugin: 'java'
jar {
manifest {
attributes 'Main-Class': 'com.package.app.Class'
}
}
Antwoord 9, autoriteit 2%
Probeer deze opdracht om de jar op te nemen:
java -cp yourJarName.jar your.package..your.MainClass
Antwoord 10, autoriteit 2%
Als u Maven gebruikt, neem dan het volgende op in de pom
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.4.2.RELEASE</version>
</parent>
<properties>
<java.version>1.8</java.version>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
Antwoord 11
Voor mij hielp geen van de antwoorden echt – ik had het manifest-bestand op de juiste plaats, met de hoofdklasse en alles. Waar ik over struikelde was dit:
Waarschuwing: het tekstbestand van waaruit u het manifest maakt, moet
eindigen met een nieuwe regel of regelterugloop. De laatste regel zal niet zijn
correct geparseerd als het niet eindigt met een nieuwe regel of een regelterugloop.
(bron). Het toevoegen van een nieuwe regel aan het einde van het manifest loste het op.
Antwoord 12
Het MAVEN-probleem is dat het probeert om het eerste MANIFEST.MF-bestand van de eerste bibliotheek van afhankelijkheden op te nemen in plaats van THE OUR OWN MANIFEST.MF WANNEER JE ARTIFACTEN GEBRUIKT!.
- Hernoem uwjar.jar naar uwjar.zip
- Open MANIFEST.MF-bestand van META-INF\MANIFEST.MF
-
Kopieer het echte MANIFEST.MF dat al door MAVEN . in uw project wordt gegenereerd
Dat omvat zoiets:Manifest-versie: 1.0
Hoofdklasse: yourpacket.yourmainclass (bijvoorbeeld info.data.MainClass) -
Vervang de inhoud van MANIFEST.MF van youjar.zip ermee.
- Hernoem uwjar.zip naar uwjar.jar terug.
- Java -jar yourjar.jar werkt nu perfect.
OF!
Maak eenvoudig uw eigen MANIFEST.MF en:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.2.0</version>
<configuration>
<archive>
<manifestFile> Your path like: src/main/resources/META-INF/MANIFEST.MF </manifestFile>
<index>true</index>
<manifest>
<addClasspath>true</addClasspath>
</manifest>
</archive>
</configuration>
</plugin>
Maar als u het maven-paneel (of de maven-opdrachtregel) gebruikt, kunt u het dwingen om een eigen manifest te genereren en het in het JAR-bestand op te nemen.
-
Voeg deze code toe aan het buildgedeelte van u pom.xml:
<plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-assembly-plugin</artifactId> <version>3.2.0</version> <executions> <execution> <phase>package</phase> <goals> <goal>single</goal> </goals> </execution> </executions> <configuration> <descriptorRefs> <descriptorRef>jar-with-dependencies</descriptorRef> </descriptorRefs> <archive> <index>true</index> <manifest> <addClasspath>true</addClasspath> <mainClass> yourpacket.yourmainclass (for exmaple info.data.MainClass)</mainClass> </manifest> <manifestEntries> <mode>development</mode> <url>${project.url}</url> </manifestEntries> </archive> </configuration> </plugin>
-
Open het MAVEN-paneel (in Intellij) en voer “Installeren” uit. Het genereert het MANIFEST-bestand en compileert de eigenschap van het JAR-bestand met alle afhankelijkheden in de map “Target”. Het wordt ook geïnstalleerd in de lokale maven-repository.
Antwoord 13
Ik had vandaag hetzelfde probleem. Mijn probleem was dat ik META-INF naar de bronnenmap verplaatste.
Antwoord 14
Ik kreeg zojuist dezelfde fout.
Als je gradle
gebruikt, voeg dan gewoon de volgende toe in je gradle.build
:
apply plugin: 'java'
jar {
manifest {
attributes 'Main-Class': 'com.company.project.MainClass'
}
}
Waar com.company.project.MainClass
pad naar ur class met public static void main(String[] args)
methode.
Antwoord 15
Als de jar niet volgt de regels, het is geen uitvoerbare pot.
Antwoord 16
Ik had hetzelfde probleem en het is nu opgelost 🙂
Volg gewoon de onderstaande stappen en de fout kan van alles zijn, maar de onderstaande stappen maken het proces soepeler. Ik besteed veel tijd aan het vinden van de oplossing.
1.Probeer de Eclipse opnieuw te starten (als u Eclipse gebruikt om een JAR-bestand te bouwen)
–> Eigenlijk heeft dit mijn probleem geholpen bij het correct exporteren van het JAR-bestand.
2.Nadat de eclipse opnieuw is opgestart, probeert u te zien of uw eclipse de hoofdklasse/methode kan herkennen aan uw Java-project –> klik met de rechtermuisknop –> Uitvoeren als –> Configuraties uitvoeren –> Hoofd –> klik op de knop Zoeken om te zien of uw eclipse uw hoofdklasse kan opzoeken in het JAR-bestand.
–> Dit is voor de validatie dat het JAR-bestand het toegangspunt tot de hoofdklasse zal hebben.
-
Exporteer hierna uw Java Dynamic-project als “Uitvoerbare JAR”-bestand en niet als JAR-bestand.
-
Kies in de Java-startconfiguratie uw hoofdklasse.
-
Nadat het jar-bestand is geëxporteerd, gebruikt u het onderstaande commando om het uit te voeren.
java -cp [Uw JAR].jar [compleet pakket].MainClass
bijv.: java -cp AppleTCRuleAudit.jar com.apple.tcruleaudit.classes.TCRuleAudit -
U krijgt mogelijk te maken met de niet-ondersteunde Java-versiefout. de oplossing is om de java_home in je shell bash-profiel aan te passen aan de java-versie die is gebruikt om het project in eclipse te compileren.
Hopelijk helpt dit! Laat het me weten als je nog steeds problemen hebt.
Antwoord 17
Als je de opdrachtregel gebruikt om .jar samen te stellen, is het mogelijk om naar de main te verwijzen zonder een Manifest-bestand toe te voegen. Voorbeeld:
jar cfve app.jar TheNameOfClassWithMainMethod *.class
(param “e” doet dat: TheNameOfClassWithMainMethod is een naam van de klasse met de methode main() en app.jar – naam van uitvoerbaar .jar en *.class – alleen alle klassenbestanden om samen te stellen)
Antwoord 18
Ik had hetzelfde probleem. Veel van de hier genoemde oplossingen gaven me niet het hele plaatje, dus ik zal proberen je een samenvatting te geven van hoe je Jar-bestanden inpakt vanaf de opdrachtregel.
-
Als u uw
.class
-bestanden in pakketten wilt hebben, voegt u het pakket toe aan het begin van de.java
.Test.java
package testpackage; public class Test { ... }
-
Om uw code te compileren met uw
.class
-bestanden die eindigen met de structuur die wordt gegeven door de pakketnaam, gebruik:javac -d . Test.java
De
-d .
zorgt ervoor dat de compiler de gewenste directorystructuur maakt. -
Bij het inpakken van het bestand
.jar
moet je de jar-routine instrueren hoe het moet worden verpakt. Hier gebruiken we de optiesetcvfeP
. Dit is om de pakketstructuur te behouden (optieP
), het ingangspunt op te geven zodat het manifestbestand zinvolle informatie bevat (optiee
). Optief
laat je de bestandsnaam specificeren, optiec
creëert een archief en optiev
stelt de uitvoer in op uitgebreid. De belangrijkste dingen om hier op te letten zijnP
ene
.Dan komt de naam van de pot die we willen
test.jar
.Dan komt het beginpunt .
En dan komt
-C . <packagename>/
om de klassenbestanden uit die map te halen, waarbij de mappenstructuur behouden blijft.jar cvfeP test.jar testpackage.Test -C . testpackage/
-
Controleer uw
.jar
-bestand in een zip-programma. Het zou de volgende structuur moeten hebbentest.jar
META-INF | MANIFEST.MF testpackage | Test.class
Het MANIFEST.MF moet het volgende bevatten
Manifest-Version: 1.0 Created-By: <JDK Version> (Oracle Corporation) Main-Class: testpackage.Test
Als u uw manifest met de hand bewerkt zorg ervoor dat u de nieuwe regel aan het einde houdt anders herkent Java het niet.
-
Voer uw
.jar
-bestand uit metjava -jar test.jar
Antwoord 19
Persoonlijk denk ik dat alle antwoorden hier de vraag verkeerd begrijpen. Het antwoord hierop ligt in het verschil in hoe spring-boot de .jar bouwt. Iedereen weet dat Spring Boot een manifest als dit opzet, dat verschilt van ieders aanname dat dit een standaard .jar-lancering is, wat het al dan niet kan zijn:
Start-Class: com.myco.eventlogging.MyService
Spring-Boot-Classes: BOOT-INF/classes/
Spring-Boot-Lib: BOOT-INF/lib/
Spring-Boot-Version: 1.4.0.RELEASE
Created-By: Apache Maven 3.3.9
Build-Jdk: 1.8.0_131
Main-Class: org.springframework.boot.loader.JarLauncher
Misschien moet het worden uitgevoerd met org.springframework.boot.loader.JarLauncher
op het klassenpad?
Antwoord 20
Elk uitvoerbaar jar-bestand Moet worden uitgevoerd door te klikken of door opdrachtprompt te gebruiken, zoals java -jar app.jar (gebruik “als pad van jar ruimte bevat” – bijv. java -jar “C:\mapnaam\app.jar” ). Als uw uitvoerbare jar niet actief is, wat betekent dat het niet correct is gemaakt.
Voor een beter begrip, pak het jar-bestand uit (of bekijk het met een tool, want Windows 7-Zip is een goede optie) en controleer het bestand onder /META-INF/MANIFEST.MF. Als je een item vindt zoals
Hoofdklasse: uw.pakket.naam.ClaaswithMain – dan is het goed, anders moet u het opgeven.
Houd rekening met het toevoegen van Main-Class-items aan het MANIFEST.MF-bestand, controleer waar u het opslaat!
Antwoord 21
U kunt deze stap gewoon volgen
Maak een jar-bestand met
jar -cfm jarfile-name manifest-filename Class-file name
Terwijl het jar-bestand wordt uitgevoerd, kunt u dit eenvoudig zo uitvoeren
java -cp jarfile-name main-classname
Antwoord 22
Je hebt het jar-bestand misschien niet goed gemaakt:
ex: optie m ontbreekt bij het maken van een pot
De volgende werken:
jar -cvfm MyJar.jar Manifest.txt *.class
Antwoord 23
Voor mij deed deze fout zich simpelweg voor omdat ik vergeten was Eclipse te vertellen dat ik een uitvoerbaar jar-bestand wilde en niet een eenvoudig bibliotheek-jar-bestand. Dus wanneer u het jar-bestand in Eclipse maakt, zorg er dan voor dat u op het juiste keuzerondje klikt
Antwoord 24
De bovenstaande antwoorden waren slechts gedeeltelijk nuttig voor mij. java -cp
maakte deel uit van het antwoord, maar ik had meer specifieke informatie nodig over hoe de klasse te identificeren die moest worden uitgevoerd. Dit is wat voor mij werkte:
Stap 1: vind de les die ik moet uitvoeren
jar tf /path/to/myjar.jar | more
De bovenste regels van het resultaat waren:
META-INF/
META-INF/MANIFEST.MF
somepath/
somepath/App.class
META-INF/maven/
...
App.class bevat de hoofdklasse die moet worden uitgevoerd. Ik weet niet 100% zeker of je altijd kunt aannemen dat de les die je nodig hebt de eerste is, maar het was voor mij. Als dat niet zo is, kan ik me voorstellen dat het niet al te moeilijk is om grep te gebruiken om bibliotheekgerelateerde resultaten uit te sluiten om de klassenlijst terug te brengen tot een hanteerbare grootte.
Vanaf daar was het makkelijk: ik gebruik gewoon dat pad (minus het “.class” achtervoegsel):
java -cp /path/to/myjar.jar somepath/App
Antwoord 25
Ik heb een nieuwe oplossing gevonden voor het genereren van slechte manifesten!
- Open het jar-bestand met een zip-editor zoals WinRAR
-
Klik op voor META-INF
-
Toevoegen of bewerken
-
Toevoegen:
-
Maak een tekstbestand met de naam MANIFEST.MF in een map met de naam META-INF
en voeg de volgende regel toe:- Manifest-versie: 1.0
- Hoofdklasse: package.ex.com.views.mainClassName
-
Sla het bestand op en voeg het toe aan de zip
-
-
Bewerken:
- Sleep het bestand naar buiten, wijzig MANIFEST.MF om de vorige regel toe te voegen
-
-
Open cmd en typ: java -jar c:/path/JarName.jar
Het zou nu goed moeten werken!
Antwoord 26
In mijn geval is het probleem <pluginManagement>
onder <build>
waardoor dingen niet goed kunnen werken.
Mijn originele pom.xml:
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
...
...
...
</pluginManagement>
</build>
Na het verwijderen van <pluginManagement>
is de fout verdwenen.
Antwoord 27
Omdat je MANIFEST.MF hebt toegevoegd, denk ik dat je de volgorde van Field in dit bestand moet overwegen. Mijn omgeving is java version "1.8.0_91"
en mijn MANIFEST.MF zoals hier
// MANIFEST.MF
Manifest-Version: 1.0
Created-By: 1.8.0_91 (Oracle Corporation)
Main-Class: HelloWorldSwing
// run
~ java -jar HelloWorldSwing.jar
no main manifest attribute, in HelloWorldSwing.jar
Echter, dit zoals hieronder loopt door
Manifest-Version: 1.0
Main-Class: HelloWorldSwing
Created-By: 1.8.0_91 (Oracle Corporation)
//this run swing normally
Antwoord 28
(eerste bericht – dus het is misschien niet schoon)
Dit is mijn oplossing voor OS X 11.6, het op Maven gebaseerde Netbeans 8.2-programma. Tot nu toe is mijn app 100% Netbeans – geen aanpassingen (slechts een paar shell-ontsnappingen voor het onmogelijke!).
Nadat ik de meeste antwoorden hier en elders zonder resultaat had geprobeerd, keerde ik terug naar de kunst van “gebruik wat werkt”.
Het beste antwoord hier (olivier-refalo thanx) leek de juiste plek om te beginnen, maar was het niet helpen.
Kijkend naar andere projecten die wel werkten, merkte ik enkele kleine verschillen op in de manifestregels:
- addClasspath, classpathPrefix waren afwezig (verwijderd)
- mainClass miste de “com.” (gebruikt de NB -> Project
Eigenschappen->Uitvoeren->Hoofdklasse->Bladeren om op te geven)
Ik weet niet zeker waarom (ik ben pas 3 maanden in Java) of hoe, maar kan alleen maar zeggen dat dit werkte.
Hier is alleen het gewijzigde manifestblok dat wordt gebruikt:
<manifest>
<mainClass>mypackage.MyClass</mainClass>
</manifest>
Antwoord 29
Om één punt duidelijk te maken over
Main-Class: <packagename>.<classname>
Als je geen pakket hebt, moet je dat deel negeren, zoals dit:
Main-Class: <classname>
Antwoord 30
Ik heb dit geprobeerd en het werkte voor mij.
mvn schoon installatiepakket zou moeten werken.
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>