Comentarii

Copiați linkul Citat răspuns

maven

eduramiba comentat 6 martie 2018

Întrucât utilizarea pluginului maven shade pentru a crea un vas de grăsime este cunoscut ca fiind problematic, deoarece poate suprascrie fișiere amestecând borcane (https://product.hubspot.com/blog/the-fault-in-our-jars-why-we- stop-building-fat-borcane), folosim în prezent cu succes o modalitate mai sigură de a implementa lambdas cu dependențe: un singur zip cu toate borcanele într-un folder lib (așa cum este documentat în https://docs.aws.amazon.com/en_en /lambda/latest/dg/create-deployment-pkg-zip-java.html)

Exemplu de cod al modului în care o facem în maven:

Și fișierul bin.xml:

Textul a fost actualizat cu succes, dar s-au întâlnit aceste erori:

sapessi comentat 6 martie 2018

Vă mulțumim pentru feedback-ul @eduramiba - M-am întrebat dacă este timpul să construiți un plugin maven specific Lambda pentru a împacheta o aplicație și pentru a slăbi cât mai mult posibil borna de ieșire. Voi păstra acest lucru deschis și o voi gândi bine. Cu siguranță voi analiza adăugarea pluginului de asamblare ca alternativă la eșantioanele și arhetipurile noastre.

omenirea comentat 7 martie 2018

Este bine să știți acest mod de a-l împacheta. Mulțumesc @eduramiba !

Iuchar comentat 21 iunie 2018

@eduramiba Vă mulțumim! Cum ați exclude tomcatul încorporat în acest caz?

eduramiba comentat 21 iunie 2018

Dar dacă dependența dvs. a oferit domeniul de aplicare, aceasta nu va fi copiată deoarece includeScope este timpul de execuție.

eduramiba comentat 21 iunie 2018 •

De asemenea, intrările manifestului jar nu sunt de fapt necesare în timpul rulării lambda, deoarece vor încărca toate borcanele în folderul lib.

Iuchar comentat 21 iunie 2018 •

Am schimbat abordarea dvs. puțin și funcționează și (trebuie doar să configurați pluginul de asamblare în acest fel):

eugenevd comentat 26 iunie 2018

Am încercat ambele exemple sugerate furnizate.
Primele rezultă în propriul meu cod (Handler) care trebuie adăugat în propriul borcan, apoi, împreună cu celelalte borcane de dependență, este introdus în „lib /” direct în interiorul fișierului zip.
lib/myHandler.jar
lib/dep1.jar

Al doilea exemplu pune toate dependențele în lib/din nou, dar la rădăcina zip structura directorului;
de exemplu:
com/company/Handler.class

lib/dep1.jar

Oricum, am înțeles
Clasa nu a fost găsită: com.company.Handler: java.lang.ClassNotFoundException

Am încercat ambele moduri de a defini handlerul:

Ce îmi lipsește?

fundal
Folosirea pluginului maven shade a fost singura modalitate prin care am putut să implementez funcționarea, dar după ce am adăugat dependența bouncycastle, am primit o eroare:
Eroare la crearea borcanului umbrit: rezumatul fișierului de semnătură nevalid pentru atributele principale Manifest

Există sugestii pentru a elimina semnăturile:

dar cu siguranță acestea vor fi respinse.
Deci, concluzia mea a fost să găsesc o modalitate de a împacheta toate borcanele de dependență așa cum este, de unde sugestiile postărilor anterioare aici.

sapessi comentat 26 iunie 2018 •

Bună @eugenevd - Sunt pe drum chiar acum, dar voi încerca să replic problema dvs. cu pluginul Shade și să văd dacă putem găsi o soluție joi. În ceea ce privește întrebările legate de pluginul de asamblare, voi lăsa să intervină pe @eduramiba și @Juchar, deoarece ei știu în mod clar mai mult decât mine pe această temă.

Iuchar comentat 27 iunie 2018

Bună @eugenevd - configurația asamblării pe care o menționez mai sus va produce un fișier zip în urma acestor convenții.

Pentru mine a funcționat din cutie. Poate ne-ați putea arăta sam.yml, eventual eroarea dvs. se află în altă parte?

Aceasta este partea relevantă din a mea:

eugenevd comentat 27 iunie 2018

Pentru a ilustra situația mea, am furnizat acest proiect la https://github.com/eugenevd/aws-serverless-java-container și am folosit eșantionul Springboot pentru animale de companie ca bază.

Există două ramuri, câte una pentru fiecare dintre exemplele postate de @eduramiba (ramură nr.133-comentariu302648748) și @Juchar (ramură nr.113-comentariu399079415)
master nu conține modificări, cu excepția unui fișier readme.

Ramură: stăpân
Nu există modificări, folosește mvn-shade și funcționează așa cum era de așteptat (cu excepția problemelor la adăugarea de borcane semnate, cum ar fi bouncy-castle)

Sucursală: issue133-comment302648748
Rezultă un fișier ZIP care are borcanele de dependență în lib/și codul de gestionare într-un .jar, de asemenea, în lib/
Rezultatul este ClassNotFoundException

Ramură: issue133-comment399079415
Acest lucru are ca rezultat un fișier ZIP care are borcanele de dependență încă în lib/dar cu codul (ca fișiere .class) în rădăcina fișierului zip.
Rezultatul este încă ClassNotFoundException

Comentarii
M-am asigurat în fiecare caz să actualizez sam.yaml pentru a indica zip-ul corect, deoarece fiecare ramură produce un fișier zip cu un nume diferit (schimbarea ramurilor lasă în urmă zip-ul din versiunea anterioară)

Pentru a verifica din nou, după o implementare, am descărcat fișierele zip încărcate în cupă și am comparat conținutul acestora cu fișierele zip produse de „pachetul mvn”. Acestea au fost aceleași cum se aștepta.

--
@Juchar - ai cerut să vezi sam.yaml - vezi fiecare dintre aceste ramuri.
Și da, linkul pe care l-ați postat la convenție este ceea ce am lucrat și eu fără succes.

@sapessi Fără griji. Doar să reiterăm totuși; Încerc să NU folosesc pluginul de umbră. Dacă aveți un borcan de dependență semnat, acestea sunt dezactivate atunci când reorganizați conținutul așa cum face nuanța. Acesta este motivul pentru care urmăresc exemplele acestor probleme .