Na, ki tud nagyobbat mondani a fentieknél, szakmaiságban és megalapozottságban? 
Viccet félretéve, egy okból váltanám le a mavenes projektjeinket gradle-re, ha olyan jellegű performancia problémánk lenne, amin a gradle segítene, és a probléma elérne olyan szintet, hogy megérné kidobni kb. 1 hónapot az egyébként jól működő, maintenance és problémamentes projektjeink migrációjára.
Thank you to god for making me an atheist
Inkább azt mondanám, hogy új projektet már nem indítanék mavennel, és a régiek esetében egy nagyobb maintenance alkalmával megnézném a migráció lehetőségeit. A migrációhoz segítséget adna egy gradle-el nyitott projektből jövő tapasztalat
Jó én ebből a vitából kiszállok. Nem fogom megérteni sosem a régi dolgokhoz ragaszkodást. Fiatal vagyok hozzá.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
[ Szerkesztve ]
Ha keresztbe-kasul ismersz valamit, s atlagban egy problemat 3mp megoldani neked benne, akkor nagyon nyomos erv kell ahhoz, hogy lecsereld valami masra, amiben ugyanez a folyamat a kompetenciad hianya miatt eltartana vagy 1 napig.
Nalunk minden regi es minden uj projekt is maven, szimplan azert, mert van par emberunk, aki nagyon ert hozza. Ok tenyleg kb. 5 perc alatt a legkomplexebb projekteket is atlatjak, mig Gradle-hez nincsen ilyen emberunk. A build time meg nem kritikus.
Persze lenne haszna gradle-zni, legalabb lenne eselye kialakulni benne mely kompetencianak. Ha ma kezdenek Javazni, biztos azzal kezdenek. Igy viszont, hogy teljesen otthonos terep a maven, foleg ezt hasznalom, itthon is. Volt projekt amit gradle-lel kezdtem, de semmi nem vitt ra utana, hogy a kovetkezot is azzal csinaljam. Van boven mas szakterulet, ahol tobb hasznot hoz a raforditott tanuloido.
I am having fun staying poor.
És van igény ott új dolgok megtanulására (kérlek ne pejoratív érelemben értsd). Nálunk a mavent írtják - szerencsére. Persze ez csak marketing de: [link] .
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
Alapvetoen van, de elsosorban business case-ekhez kototten. Meg igyekszunk mindig uj dolgokat behozni, ha hasznos, vagy hosszan tarto megoldast adhat. De nalunk mindenki erosen devops/automated tester/data magus is egyben, s legkevesbe izgalmas/lenyeges resz az egeszben a java build. Nyilvan a magussal tuloztam, de inkabb a szeles tudas az, ami nalunk a fokusz, nem pedig a reszletekbe meno tudas egyes alteruleteken.
I am having fun staying poor.
Voltam olyan projekten, ahol már már megszállottságig fajult az új dolgok megtanulása. Hetente cseréltük le a félig magunkévá tett libeket valami fancy újra, és integráltuk bele az alkalmazásba újra és újra és újra, mindig volt valami hot topic. Brr. Na de ez a másik véglet. Talán nem kell mondanom, az alkalmazás elkészülte folyamatosan csúszott. Talás sose készült el, már nem vagyok ott, hogy ezt megtapasztalhattam volna.
Nekem annyit adott az a projekt, hogy megtanultam a világ túl gyorsan változik, hogy minden újat meg akarjak tanulni - nem is lehet - és elveszi az időt az értelmes dolgokban való elmélyüléstől. Persze megértem, hogy másokat meg csak az újdonság érdekel, és nem zavarja őket az a sok zaj a fejükben, aminek a felére holnap már senki sem emlékszik amúgy, mert csak hype volt körülötte. Azt meg végképp nem tudom hova tenni, ha valakit az alapján ítélünk meg (el?), hogy mavent vagy gradlet használ, neadjisten antot. Ha neki ettől jobb, váljon egészségére. 
Vagy menjen és vezesse le a feszkót maven irtással, addig sem zavarja a terméken dolgozó népeket. 
Amúgy utálom az xml-t, és szeretem a mavent. Há!
"ha valakit az alapján ítélünk meg (el?), hogy mavent vagy gradlet használ"
Én nem ítélek meg senkit ez alapján. Le is írtam az elején, hogy nem akarok ebből most keresztes háborút, és továbbá azt is, hogy fiatal vagyok xml-ek irogatásához. Amit leírtál szerintem szélsőséges, fontosnak tartom, hogy hozzuk be az új dologokat de nem kell a ló másik oldalára esni.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
A megfelelő build alap összerakása elhanyagolható erőforrásigényű egy átlagos projekt többi feladatához képest. Nyilván nem a legkritikusabb helyzetekben kell fejest ugrani az ismeretlenbe, de ezzel a mentalitással bele lehet ragadni technológiákba. Amúgy pont devopsos szempontból nem értem a dolgot, hiszen épp a gradle az, ami sokkal kezesebb groovy/kotlin oldalról. Compose-os projektekben befonnánk egymás haját, ha mavent kellene használni.
Abszolút egyetértek. (Éreztem benne egy rejtett üzenetet, ezért hoztam az ellenkező irányú extrém példát.)
Van egy projektem, ami egy külső dll file-t használ egy feladat elvégzéséhez. Jna-t használok. Általában működik is, de néha teljesen váratlanul Microsoft Visual C++ Runtime Library: "Buffer overrun detected! A buffer overrun has been detected which has corrupted the program's internal state." hibát dob.
Találkozott már valaki ilyen hibával, vagy van valami ötlete mi lehet a hiba? Mivel ez túlnyúlik a Java-n és inkább csak a Java-ban vagyok otthon, ezért nem tudom hogy kéne a hibát keresni.
Java 8 , Windows 10 az oprendszer és elvileg 4.8.03752 a .NET verzió. Esetleg rossz .NET verzió lenne a probléma?
[ Szerkesztve ]
Mi az a dll, amit használsz? A hiba azért van, mert a dll-ben lévő kód az általa lefoglalt memórián kívül akar írni a memóriába, amit akár más process éppen használ. Ezt figyeli a runtime és lelövi. Jobb esetben bugos a dll-ben lévő kód, rosszabb esetben valami kártevő lakik benne.
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
Ez egy régebben (10+ éve)megírt dll. Biztos nem vírusos. Eddig más programnyelvből (Delphi) lett meghívva, és ott működött jól. Talán annyi tudtam még észrevenni, hogy ha elindítom a saját programomat, és leállítom, majd újraindítom, akkor jön elő, de az bizonytalan, hogy mennyi idő múlva és hányadik újraindításnál. Elvileg a Windows újraindítása után rögtön nem csinálja.
[ Szerkesztve ]
"A megfelelő build alap összerakása elhanyagolható erőforrásigényű egy átlagos projekt többi feladatához képest." Nem ertek egyet. Ez csak akkor igaz, ha az adott build rendszerhez es az azzal szembeni kovetelmeneykhez is valaki nagyon ert. Igazabol aztan utana tok mindegy, hogy pipeline-bol mavent, vagy gradle-t hivok meg.
Projektek atlagos build ideje ket perc mavennel. Intellij meg ugyis feldolgozza az egeszet belso projekt formatumra, ami sokkal gyorsabb, foleg ha szelektiven akarsz valamit futtatni. Kiprobalnam en is elesben a Gradle-t, de nem igazan varok tole semmi valos hasznot a mi use case-unkben. Ha nagyon nem lesz semmi dolgunk, akkor majd rakerul arra is a sor. A mostani maven service template-jeink tokeletesen megfelelnek az elvarasainknak, a lecserelesukben sokkal tobb lenne a potencialis risk, mint a potencialis benefit.
I am having fun staying poor.
meg kell nézni, hogy pontosan mit és hogyan csinál, hogyan volt használva a korábbi programból és hogyan a tiedből, ha ennyiből nem derül ki akkor utána nézel, hogyan lehet debug-olni, abból biztos kiderül, hogy mi okozza a problémát
aztán vagy máshogy használod vagy át/újra kell írni
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
Mi az előnye a teljesítmény mellett? Sokkal rugalmasabb: deklaratív és procedurális egyben. Ha valami nem szokványos dolgot kell megoldani, elég egy kisebb scriptet írni benne. Nem vagy kötve a CI/CD képességeihez, és lokálisan is meg tudod azt tenni, amit a CI/CD pluginekkel támogat
Azt sem tartom valós problémának, hogy annyit kéne vele bíbelődni, hiszen a fejlesztőkörnyezetek már eléggé támogatják a nulláról kezdést is, ahogy a maven esetében. Sokkal körülményesebb a maven, de igazán nem akarok téríteni, nyilván nem kötelező, ha valaki nem akarja. Végülis lehet írni SOAP-os vagy RMI-s alkalmazást is manapság, az is működhet...
Off az off-ban: szoktam találkozni olyan emberekkel, akiknél megfigyelhető az a felfogás, hogy csak abba az irányba hajlandóak elmozdulni, amerre a kényszer viszi őket. Ők általában egy idő után benne ragadnak egy adott technológiai stackben, ami egy ideig fel sem tűnik nekik. 10 évvel később viszont már riasztó, amikor még mindig servletről beszél, és oracle + jdbc a DB megoldás mindenre
Remek, de ezekre nincs szuksegunk. Egyszer jo lenne atterni, de joval nagyobb annak az ara, mint amit itt sugallsz. Mindenkeppen eltart egy ideig, mig egy programozo csapat atszokik egy masik build tool-ra. Nyilvan van az a helyzet, amikor a relativ koltsege az atallasnak kisebb, mint a relativ haszna. Nalunk jelenleg nem az.
I am having fun staying poor.
Te tudod. Tapasztalatom szerint ez csak akarat kérdése
"eltart egy ideig, mig egy programozo csapat atszokik egy masik build tool-ra"
mvn clean test helyett gradle clean check.
[ Szerkesztve ]
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
Ha csak ennyi a különbség, akkor tényleg nem értem, miért ilyen fontos nektek, hogy Drizzt mit használ.
Tényleg nem szabad használni a switch statement-et?
De, szabad hasznalni. Viszont ha nem valamilyen factory metodusban hasznalod, akkor gyanus, hogy lenne helyette szebb, biztonsagosabb, bovithetobb OOP megoldast talalni a problemara. Nyilvan nem mindig. Akkortol jon a gond, ha tobb metodusban ugyanazon ertekkeszlet alapjan kell kulonbozo dolgokat csinalni, mert konnyen el lehet cseszni, ha bovul az ertekkeszlet.
I am having fun staying poor.
No offense, de mondjatok már egy olyan use-caset, amit csak gradle segítségével lehet megoldani....hogy kicsi visszamenjek...
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
Fordítsuk meg. Olyan use case van amit csak mavennal lehet xml nélkül?
Egy use case ahol ugyan jó a maven, de:
- Spring Boot alkalmazás
- Groovy / Kotlin dsl gradle file
- Yaml konfigurációs fileok
- Java konfigok
Nekem ebben a körneyezetben egy XML nagyon elütne / nem illene bele. De mint fentebb is beszéltük egyéni preferencia kérdése és semmi több.
[ Szerkesztve ]
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
Ha "Groovy / Kotlin dsl gradle file" ilyen van a listában, akkor ide tényleg nem jó a maven
A Spring Boot alkalmazásokra, yaml fájlokra, java konfigokra teljesen jó
De tényleg zárható, pro és kontra el lehet sokmindent mondani, egyéni preferencia kérdése. Azzal viszont tökre nem értek egyet, hogy a maven őskövület lenne....
[ Szerkesztve ]
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
Jó, nyilván szarul fogalmaztam de remélem átment amit akartam, hogy az xml ebben az esetben szarul nézne ki Groovy / Kotlin dsl helyett!
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
Teljesítményben jobb, de clean coding miatt is preferálják. A mavenben nem szokványos taszkokat, ami filekelezés/deployment témában befigyelhet, csak custom osztályokkal oldhatsz meg, ami rendkívül jó kódrejtésben
A groovy mondjuk nem a kedvencem, de ha kotlinos a projekt, akkor eleve adja magát.
Ok, de a kotlin, mint jelenség még mindig kisebb százalékát érinti a projekteknek. Egyrészt. Másrészt meg szerintem ha nem szokványos taszkok vannak, azok legtöbb esetben design problémák. De tényleg ugorjunk
[ Szerkesztve ]
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
Nagyon beakadt ez az XML. Így pár száz maven projekt és modul (és jópár plugin megírása) után azt tudom mondani, hogy az XML-t éreztem a legkevésbé problémásnak a mavenben. Csak a felszínt karcolgatod.
Én sem szeretem az XML-t különösebben, de nem érzem problémának, mert ha mavent is használ a projekt, ez nem jelenti azt, hogy egész nap ezt kell hegeszteni az egész fejlesztő cspatnak, nem olyan fajsúlyú kérdés, mint mondjuk egy frontend template, amiben egész nap hegeszt a fél társaság. A kezdeti project setup után kb. heti rendszerességű, hogy a buildünk változik, leginkább új dependency vagy verzió update miatt, ami teljesen automatikus és fájdalommentes változtatás, bármi érdemi változás ennél ritkább.
Most megnéztem egy kisebb-közepes projektet, van kb. 20 pom.xml össz. 150KB, aminek a 90+%-a copy paste-elt <dependency>, nincs mind module submodule viszonyban, tehát nem mindenhol van öröklődés, ezért a viszonylag nagy méret.
Nem XML alapján döntünk, hogy maven vagy gradle.
Saját döntési szempontok:
-mi a probléma, amit meg akarunk oldani, mit kell tudnia a buildnek és mit akarunk azon kívül kezelni.
-van-e bármi nem szokványos körülmény, amiért testre kell szabni a buildet, kell-e egyedi plugint írni hozzá, ez a néhány fajsúlyosabb probléma viszi el az idő 90%-át általában.
-hol fog futni, hova és hogyan kell illeszkednie, mivel kell integrálódnia, gondolok itt meglévő projektekre, IDE-re, teszt keretrendszerre, futtatókörnyezetre, CI/CD-re, konténerekre stb.
-karbantarthatóság, mennyire egyszerű bővíteni, vagy teljesen átalakítani
-olvashatóság, átláthatóság: pl. a konvenciók, ha ismered őket, sokat segíthetnek egy projekt megismerésében egy új résztvevő számára, míg a flexibilitás, hogy kódot tudsz írni a buildben, nem mindig előny, ha a fejlesztő csapat tényleg elkezd nagy mennyiségű kódot beleütni a buildbe.
-várható fejlesztői élmény, pl. mennyire egyszerű vele belőni a fejlesztői környezetet, milyen a tooling támogatás
-megoldás erőforrás igénye (esetleges traininggel együtt)
egyszerű használni, mennyire gyors, kiszámítható és problémamentes
-csapat meglévő kompetenciája, tanulási görbe, community, dokumentáció
-megoldás várható performanciája, ha nagyobb a projekt és számít bármit
...
...
és valahol itt egy kilométerrel lentebb van az, hogy XML-e
[ Szerkesztve ]
Thank you to god for making me an atheist
Mostmar ha elorangattad, ne hatralj ki. ![;]](http://cdn.rios.hu/dl/s/v1.gif)
Erre en csak annyit akartam irni, hogy eddig olyan 5 eves maven hasznalatom alatt egyszer sem jott szembe olyan dolog, amire nem lett volna letezo plugin, ami megoldotta a problemat. Oke, vannak azert olyanok, amitol jobbat is el tudnek kepzelni, de egyutt lehet vele elni. Van amugy joval hosszabb programozoi tapasztalatom(ossz. ~15 ev), de OOP/Java az legyen inkabb 5 ev. Ezert 5 ev a maven is.
Illetve ami pl.: Gradle-re atteressel problema lenne, hogy van egy jo szazas nagysagrendu microservice, ami azert jelenleg elegge hasonlit build projektileg. De ettol fuggetlenul mindegyikben johet fejlesztesi igeny. Ha meg hirtelen a projektek egyik fele maven, a masik fele meg gradle lenne, bevinne egy szep kis extra komplexitast.
I am having fun staying poor.
De pont ezt mondom én is Én egyébként cirka 2010 óta mavenezek, 3-4 éve meg van gradle projektünk is. Mindkettőt elismerem, de azt tényleg ne mondja senki (itt le lett írva), hogy a maven a vén szaroknak való és kuka és mindenre a megoldás a Groovy. Faszt, már bocsánat. Mindkettőnek kurvára megvan a helye
[ Szerkesztve ]
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
Senki nem vén szarozik, de a nagyobb problémát egy másik build toolra való átállás nekik jelenti.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
Ez egyáltalán nem igaz. Inkább azt mondanám, hogy a tapasztaltabbak kétszer is meggondolják, hogy érdemes-e beleölni egy csomó effortot, minimális előnyökért....amik talán nem is léteznek.
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
Persze. Erre rengeteg példát láttam az élet folyamán. Maradjunk a régi dolgoknál mert akkor nem kell nekem változtatni és ez a lényeg. Te is tudod jól, hogy töbségében ez van...
[ Szerkesztve ]
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
Ez is egy elég sarkos megfogalmazás és Te is tudod, hogy nem így van. A maven nem egy rusztikus, már senki által nem használt technológia, aminél leragadtak a vének. Innentől fogva tényleg csak egyéni/projekt preferencia, hogy mit használunk.
[ Szerkesztve ]
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
Én általánosságban értettem, de bizonyos kor felett egytől egyig akivel dolgoztam nem akart változtatni a szokásain. De ez más téma.
[ Szerkesztve ]
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
Ez emberi tulajdonság, ha odajutsz, Te is ilyen leszel
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
Remélem nem, most full komolyan.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
De. Régen attól féltem, hogy olyan leszek, mint apám. Aztán rájöttem, hogy én vagyok az apám
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
Nézd, kezdetektől fogva javazom, és család mellett sem okozott problémát a gradle, bár az ant-et szerettem a legjobban. Nyilván mindenkinek más az "egyszerű", de az XML tömöttsége eleve kevésbé áttekinthető, mint egy DSL, bármilyen jó code highlightot használsz. Karbantarthatóság szempontjából is nyilván jobb
Ami a design-t illeti, a legtöbb esetben nincsen papírforma, mindig van valami olyan körülmény, amihez alkalmazkodni kell. Amellett egy mostani CI migráció miatt jött elő, hogy a gradle build előnyben van a mavenessel szemben a deployment miatt, mivel több olyan dolgot implementáltunk benne, ami mindenhol tud futni, de a mavenes projekt ezt a CI-ra bízta.
helllo, adott egy java 8 (adoptopenjdk) maven springboot projekt.
Innen egy webservicet használnék (ekáer), úgy tűnik resttemplate-el. A programozás része eddig egyszerű volt, de a rendszergazda rész megint szívat, mivel köszönhetően a tetves google-nek ez is SSL...
Jön is az imádott sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Ezen szeretnék túljutni a lehető leggyorsabban, és legegyszerűbben. Nem érdekel az úgynevezett "biztonság". Hordozhatóvá szeretném csinálni, ilyen cacertes minden gépen ahol fut létrehozós, mindent servicet amit használ letöltős dolgokat el szeretném kerülni.
Azt szeretném, hogy az intellij fejlesztőkörnyezetből, meg war-ba csomagolva és akárhol indítva is ugyanúgy működjön, mindenféle gépenként rendszergazdás tákolás nélkül.
úgy szeretném mint böngészőből, be az url azt jóvan, működik, nem cert marháskodik.
Hogy érhetem el ezt? Googlen nem működő, vagy nem ide vonatkozó, vagy hiányos leírásokat találtam csak.
[ Szerkesztve ]
hitler, sztálin, micro usb
Áh, mavenes a projekt, ott a bibi, használj gradle-t, az ezt is megoldja.
Nyilván pontos válaszhoz kéne egész pontos infó, hogy a TLS handshake melyik ponton döglik, pl. openssl s_client kimenet, de ágyúval verébre megoldás itt:
https://stackoverflow.com/a/45444355
Thank you to god for making me an atheist
Ez se nyert: https://pastebin.com/X4ibhvWh
Beletákolva valami httpclient függőséget már elindul, de amikor kellene csinálnia, akkor:org.springframework.web.client.HttpClientErrorException: 400 Bad Request at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:85) at org.springframework.web.client.RestTemplate.handleResponse(RestTemplate.java:707) at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:660) at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:620) at org.springframework.web.client.RestTemplate.postForEntity(RestTemplate.java:414)
Az eredeti hiba a szokásos: https://pastebin.com/2RmS1DHS
[ Szerkesztve ]
hitler, sztálin, micro usb
ja igen, végül is műxik, ezt a szerver dobja vissza.
[ Szerkesztve ]
hitler, sztálin, micro usb
Sziasztok!
Friss Windows-om van. Még nincs Java és Spring Tool Suite sem. Spring Boot használatához elég a JDK SE vagy JDK EE kell?
Gondolom ha Tomcat-et használok akkor nincs szükség az EE-re... 
Köszi!
[ Szerkesztve ]
A kis emberek más emberekről beszélnek, a középszerű emberek eseményekről, a nagy emberek pedig ötletekről beszélnek.
Jdk SE eleg. En mondjuk inkabb Intellij community-val allnek neki, meg ha joval baratsagtalanabb is, mint az Ultimate. De azert arra meg nem vettem ra magam, hogy otthonra is megvegyem az Ultimate-et. Nehany pluginnal a community is eleg jo a Springhez.
I am having fun staying poor.
Gradle script, ami telepíti a certificate-et?
Köszi! Egyelőre csak tanulom - gyakorlom és a tanfolyam amit követek STS-t használ...
A kis emberek más emberekről beszélnek, a középszerű emberek eseményekről, a nagy emberek pedig ötletekről beszélnek.
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
