Ik heb het hele project opgeschoond door lokale mappen zoals ~/.gradle, ~/.m2~./androiden ~/workspace/project/.gradleen kies File -> Invalidate Caches / Restart...in Android Studio.
Nu leidt de uitvoering van het commando ./gradlewtot de volgende uitvoer:
usr$ ./gradlew tasks
Error: Could not find or load main class org.gradle.wrapper.GradleWrapperMain
Onnodig te zeggen dat ik te veel heb verwijderd, de vraag is hoe dit weer kan worden gerepareerd? Hebben jullie ideeën hoe dit op te lossen?
Antwoord 1, autoriteit 100%
Uw gradle-wrapper ontbreekt, is kapot of beschadigd.
Wat is gradle wrapper:
gradlewis het uitvoerbare bestand van de gradle-wrapper – batchscript op Windows en shellscript elders. Wanneer het wrapper-script wordt aangeroepen, downloadt het de gedefinieerde gradle-versie en voert het uit. Door de wrapper met uw project te distribueren, kan iedereen ermee werken zonder Gradle vooraf te hoeven installeren. Sterker nog, gebruikers van de build gebruiken gegarandeerd de versie van Gradle waarvoor de build is ontworpen.
Getrapte wrapper herstellen:
Vroeger moest je een wrapper-taak toevoegen aan je build.gradle om de gradle-wrapper en al zijn afhankelijkheden te herstellen. Bijvoorbeeld:
task wrapper(type: Wrapper) {
gradleVersion = '4.1'
}
Nieuwere versies van gradle vereisen dit niet. Het is nu een ingebouwde taak. Gewoon rennen:
gradle wrapper
U kunt ook extra vlaggen opgeven om versies enz. te specificeren
gradle wrapper --gradle-version 6.2 --distribution-type all
Wanneer u deze taak uitvoert, worden een gradle-wrapperscript en de vereiste jar-bestanden toegevoegd aan uw bronmappen. Eigenschappen worden opgeslagen in gradle/wrapper/gradle-wrapper.properties
(Mogelijk moet u gradle lokaal installeren om dit uit te voeren. brew install gradlebijvoorbeeld op mac. Zie meer gedetailleerde instructies hier)
Waarom ontbrak het in de eerste plaats?
OP lijkt iets te hebben verwijderd waarvan de gradle-wrapper afhankelijk is.
Maar een veelvoorkomende reden is dat een .gitignore-invoer voorkomt dat wrapper-jars in git worden ingecheckt. Merk op dat de .gitignore in feite in de bronmap kan staan, of een globale in de thuismap van je gebruiker of de globale configuratie van git. Het is gebruikelijk om een *.jarinvoer in .gitignore te hebben.
Je kunt een uitzondering toevoegen voor jar-bestanden van gradlew in .gitignore
*.jar
!gradle/wrapper/gradle-wrapper.jar
of voeg de wikkelpot geforceerd toe aan git
git add -f gradle/wrapper/gradle-wrapper.jar
ref: Gradle Wrapper
Antwoord 2, autoriteit 95%
Naast het antwoord van @RaGe kan de situatie zijn waar ik mee te maken kreeg, waarbij ik een globale git negeer had die .jarbestanden negeerde en dus de gradle wrapper jar nooit werd vastgelegd. Dus ik kreeg die fout op de Jenkins-server na een poging tot /var/lib/jenkins/my_project/gradlew build. Ik moest expliciet een toevoeging van de pot forceren en vervolgens committen:
git add -f gradle/wrapper/gradle-wrapper.jar
Antwoord 3, autoriteit 25%
Wat voor mij werkte, is om het eerst uit te voeren:
gradle wrapper
Na een succesvolle build kon ik
. uitvoeren
./gradlew assembleRelease
Opmerking: om
gradle wrapperuit te voeren, voer je eerstbrew install gradleuit. Als de installatie is gelukt, voert ugradle wrapperuit vanaf de hoofdmap van het project.
Bron en bedankt: http://gradle.org/docs/current/userguide/ gradle_wrapper.htmlen https://stackoverflow.com/users/745574/rage
Antwoord 4, autoriteit 21%
In mijn geval was het een globale .gitignore, zoals uitgelegd in het antwoord van @HankCa.
In plaats van de jar krachtig toe te voegen, wat je moet onthouden om te doen in elk Gradle-project, heb ik een overschrijving toegevoegd om de wrapper-jar opnieuw op te nemen in mijn globale .gitignore:
*.jar
!gradle/wrapper/gradle-wrapper.jar
Dit is handig voor mij omdat ik veel projecten heb die Gradle gebruiken; Git zal me er nu aan herinneren om de wikkelpot toe te voegen.
Deze overschrijving werkt zolang er geen mappen boven gradle-wrapper.jar(zoals gradleen wrapper) worden genegeerd — git zal om prestatieredenen niet afdalen naar genegeerde mappen.
Antwoord 5, autoriteit 12%
In mijn geval heb ik de submap wrapperweggelaten tijdens het kopiëren van de map gradleen kreeg dezelfde foutmelding.
Kon hoofdklasse org.gradle.wrapper.GradleWrapperMain niet vinden of laden
zorg ervoor dat je de juiste mappenstructuur hebt als je de wrapper vanaf een andere locatie kopieert.
├── build.gradle gradiënt └── wikkel │ ├── gradle-wrapper.jar │ └── gradle-wrapper.properties ├── gradlew ├── gradlew.bat └── settings.gradle
Antwoord 6, Autoriteit 4%
U bent waarschijnlijk ontbreken gradle-wrapper.jarbestand onder directory gradle/wrapperin uw project.
U moet dit bestand via dit script in build.gradle bestand, zoals hieronder te genereren,
task wrapper(type: Wrapper) {
gradleVersion = '2.0' // version required
}
en uit te voeren opdracht:
gradle wrapper
Met gradle 2.4 (of hoger) kunt u het opzetten van een wrapper zonder toevoeging van een speciale opdracht:
gradle wrapper --gradle-version 2.3
of
gradle wrapper --gradle-distribution-url https://myEnterpriseRepository:7070/gradle/distributions/gradle-2.3-bin.zip
Alle details zijn te vinden deze link
Antwoord 7, Autoriteit 3%
Ik volgde de antwoorden van boven toen ik liep in deze. En als u met dit probleem dan zorg ervoor om kracht te duwen zowel pot en eigenschappen bestanden. Na deze twee, ik gestopt met het krijgen van deze kwestie.
git add -f gradle/wrapper/gradle-wrapper.jar
git add -f gradle/wrapper/gradle-wrapper.properties
Antwoord 8, Autoriteit 2%
U kunt ook kopiëren de gradlew.bat in je hoofdmap en kopieer de gradlew-wrapper in gradlew map.
Dat is werk voor mij.
Antwoord 9, Autoriteit 2%
Bij mij (via windows 10) gradlew.bat de volgende regels code heeft in:
set DIRNAME=%~dp0
if "%DIRNAME%" == "" set DIRNAME=.
set APP_BASE_NAME=%~n0
set APP_HOME=%DIRNAME%
De variabele APP_HOME is in wezen de hoofdmap van het project, dus als dit op de een of andere manier in de war raakt, krijg je:
Fout: kan hoofdklasse niet vinden of laden
org.gradle.wrapper.GradleWrapperMain
Voor mij was dit in de war omdat mijn projectmapstructuur een ampersand (&) bevatte. Bijv. C:\Test&Dev\MijnProject
Gradel probeerde dus het bestand gradle-wrapper.jar te vinden in een hoofdmap van C:\Test (alles na en inclusief de ‘&’)
Ik heb dit gevonden door de volgende regel toe te voegen onder de ingestelde regel APP_HOME=%DIRNAME% hierboven. Voer vervolgens het bat-bestand uit om het resultaat te zien.
echo "%APP_HOME%"
Er zullen een paar andere ‘speciale tekens’ zijn die een pad/map kunnen breken.
Antwoord 10, autoriteit 2%
Ik zag dezelfde fout, maar in mijn geval was het een nieuwe Git-installatie zonder LFS geïnstalleerd. De betreffende repo was ingesteld met LFS en de gradle-wrapper.jar was in LFS, dus het bevatte alleen een verwijzing naar de LFS-server. De oplossing was simpel, voer gewoon uit:
git lfs install
En een nieuwe kloon deed het. Ik veronderstel dat git lfs pullof gewoon een git pullook had kunnen helpen, maar de persoon met het probleem besloot in plaats daarvan een nieuwe kloon te doen.
Antwoord 11
@HankCa heeft het probleem ook in mijn geval opgelost. Ik besloot om mijn gevaarlijke **/*.jarnegaties te veranderen in voor zichzelf sprekende, zoals src/**/lib/*.jarom dergelijke problemen in de toekomst te voorkomen . Negeren die beginnen met **/* is een beetje te gevaarlijk, althans voor mij. En het is altijd een goed idee om het idee achter een .gitignore-rij te krijgen door er gewoon naar te kijken.
Antwoord 12
In mijn geval raakte gradle-wrapper.jar beschadigd na het vervangen van een aantal bestanden. Terugkeren naar de originele loste het probleem op.
Antwoord 13
Ik heb dit probleem opgelost met de volgende oplossing (misschien helpt het iemand):
Controleer gewoon of de bovenliggende mappen van uw projectmap namen hebben met spaties of andere verboden tekens. Zo ja – verwijder het.
“C:\Users\someuser\Test Projects\testProj” – in dit geval moet “Test Projects” “TestProjects” zijn.
Antwoord 14
In mijn geval had ik de mappen gradlew en gradle uit het project verwijderd.
Herstel schone build-taken via “Run Gradle Task” vanuit het Gradle Projects-venster in intellij
Antwoord 15
Op Gradle 5.x gebruik ik:
wrapper {
gradleVersion = '5.5.1'
}
Antwoord 16
Ik krijg deze foutmelding omdat mijn app in een map stond met een Arabische naam en ik los het op door de Arabische mapnaam te wijzigen in een Engelse en het werkt prima.
Zorg er dus voor dat het hele pad van uw app in het Engels is geschreven.
Antwoord 17
Voor Gradle versie 5+ loste deze opdracht mijn probleem op:
gradle wrapper
https://docs.gradle.org/current/userguide /gradle_wrapper.html#sec:adding_wrapper
Antwoord 18
Ik heb gradle verwijderd en opnieuw geïnstalleerd en vervolgens een nieuwe wrapper gemaakt.
$ sudo apt remove gradle
$ sudo apt-get install gradle
$ gradle wrapper
Antwoord 19
Ons probleem was dat het bestand gradle-wrapper.jarsteeds beschadigd raakte door git.
We moesten een bestand .gitattributestoevoegen met de regel:
*.jar binary
Verwijder vervolgens de jar uit git en voeg hem opnieuw toe. Vreemd genoeg was dat alleen nodig voor een van onze repo’s, maar niet voor de andere.
Antwoord 20
Ik had dit net in OS X en heb het als volgt opgelost:
$ gradle wrapper
Nu kunt u de opdracht builduitvoeren,
$ ./gradlew build
Antwoord 21
De probleemstelling is eenvoudig dat het niet in staat is om het uitvoerbare hoofdklassebestand te vinden.
Als u gradle wrapper in uw project gebruikt, zou u de onderstaande structuur moeten hebben
├── gradle
│ └── wrapper
│ ├── gradle-wrapper.jar
│ └── gradle-wrapper.properties
├── gradlew
├── gradlew.bat
Als je ./gradlew uitvoert, zoekt het naar het classpath en volgens de code in gradlew of gradlew.bat is er een regel om gradle-wrapper.jar aan classpath toe te voegen
CLASSPATH=$APP_HOME/gradle/wrapper/gradle-wrapper.jar
In mijn geval was er een invoer in de .gitignore als *.jar die de gradle-wrapper.jar ook uitsloot toen de eerste commit werd gemaakt.
Dus, om het bestand terug te halen, moet je onderstaande taak uitvoeren
gradle wrapper
Als je de nieuwste gradle-versie niet gebruikt, moet je een wrapper-taak hebben in build.gradle zoals hieronder. Dit definieert welke gradle-versie in de wrapper wordt gebundeld. Voor de nieuwste versies van gradle is de wrapper-taak impliciet.
task wrapper(type: Wrapper) {
gradleVersion = '4.8'
//change this as per your project. Refer to distributionUrl in gradle-wrapper.properties to confirm the version
}
Zodra u de taak heeft uitgevoerd, wordt de gradle-wrapper-4.8.jar gedownload en in de map gradle/wrapper geplaatst (zoals uitgelegd in de bovenstaande boomstructuur). Hernoem het bestand naar gradle-wrapper.jar
Aangezien *.jar echter is uitgesloten in het .gitignore-bestand, kan ik het nog steeds niet inchecken om het op te slaan in github.
Voeg dus de onderstaande regel toe aan het .gitignore-bestand om gradle-wrapper.jar uit te sluiten van de lijst met genegeerde potten vanwege *.jar.
!gradle-wrapper.jar
Git heeft feitelijk voorbeeld .gitignore-bestanden gedeeld voor alle programmeertalen.
Raadpleeg voor gradle andjava
- https://github.com/github/gitignore/blob/master /Gradle.gitignore
- https://github.com/github/gitignore/blob/master /Java.gitignore
Antwoord 22
Als je MacOS gebruikt en het bestand ./gradle/wrapper/gradle-wrapper.jaral bestaat maar nog steeds dezelfde fout geeft, kan dit komen door MacOS Java-machtigingen op de documenten map.
Ga naar System Preferences -> Security and Privacy -> Privacy Tab -> Files and Folders -> Javaen vink het selectievakje ‘Documentenmap’ aan (of een ander vakje dat kan verschijnen op de plek waar u uw apps vasthoudt).
Ik heb uren met dit ding gevochten, dus ik hoop dat het nuttig is voor iemand.
Antwoord 23
Ik heb zojuist gradle-wrapper.jargekopieerd van een van mijn vorige projecten van pad /android/gradle/wrapperen in mijn app geplakt op hetzelfde pad /android/gradle/wrapperen het werkte perfect.
Chillpil 🙂