File -> Project Structure -> Modules -> zaznaczasz folder src -> mark as sources

Z tego co widzę w internecie, chyba nikt nie miał tego problemu w inteliij

@Embeddable: problem jest dlatego, że próbujesz wyjść poza ramy konwencji maven. Twój folder z konfiguracją serwera aplikacyjnego powinien być w katalogu resources.
To z resources jest kopiowany na class path obok źródeł Java.
Standardowa struktura katalogów maven: https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

@eovenn: to nie masz się czym chwalić chyba? ( ͡° ʖ̯ ͡°)

@famir96: Problem z gradlem jest taki, że pozwala na zbyt dużo. Bez problemu możesz nadpisać standardowe taski, czy rozszerzyć je. Z jednej strony brzmi przydatne, jednak niekoniecznie dobrze z tym się pracuje jak standardowy task nagle zachowuje się inaczej niż w opisie dokumentacji. Z drugiej strony w mavenie aby zrobić coś niestandardowego, to jesteś skazany na pluginy, a w gradle piszesz po prostu swojego taska. Nowe projekty powstają najczęściej z gradle,Pokaż całość

@famir96: mavena masz z jaką wersja javy skonfigurowanego? (mvn -v)

@famir96: sprawdź co masz w JAVA_HOME

@blubry: w jakim katalogu jest przed mvn clean install?

@Yakooo: eh to cachowanie IntelliJ :D może napsuć krwi, czasem też pomaga Invalidate Cache and Restart

i bym się wtedy totalnie odciął od mavenCentral().

@novak00: w praktyce wszyscy będą na ciebie #!$%@?ć :D
Możesz sobie zrobić kopię artefaktów potrzebnych do budowania/uruchamiania konkretnej wersji aplikacji, ale w dużej skali to jest ból dupy. Zwłaszcza, że polityka zaciągania tranzytywnych zależności nie jest sztywna, więc dla jednej wersji gradle możesz uzyskać inny zestaw artefaktów niż dla drugiej. Jednemu developerowi się zbuduje, drugiemu nie, choć to ten sam kod źródłowy.

NaPokaż całość

@JustUseBrain:
``

Brakowało Ci fx:controller="com.mtuning.LoginController"

@JustUseBrain:
Jak budujesz jar z assembly plugin to musisz skonfigurować, żeby tworzył manifest:


com.mtuning.Launcher

@DinapeS: sprawdz build-rebuild project

@DinapeS: file -> restart and invalidate caches

@JI_Gorki: jeśli budowa projektu zajmuje kilkanaście minut, to jest zdrowo #!$%@?.
polecam do dużych projektów (wielomodułowych) jednak przemóc się i przebudować na gradle, ten ma incremental builds i wiele innych ficzerów umożliwiających szybkie budowanie (oczywiście jeśli tego nie zepsujesz)

Doszło parę linijek kodu.

@JI_Gorki: czyli zmieniła się struktura dependencji

@quwer samego wykazu nie bardzo, ale z lewej w oknie "project", na dole, masz dostęp do klas z tej biblioteki co dodałeś... Choć to słaby sposób na czytanie API

@quwer: przecież temat wsdl to jest kompletnie inna bajka i nie ma nic wspólnego z dołączaniem bibliotek!
wsdl2java to jest słowo klucz, ale trzeba się nakombinować, by nie wypluwało to gównianych klas

@filozofw: nie próbuj przenosić filozofii mavena na gradle. Odcinamy to grubą kreską.

1. od paru wersji gradle wstecz, istnieją takie configuration jak api i implementation. Używanie tego drugiego chroni przez mavenową patologią, czyli wyciekiem tranzytywnych zależności do consumerów biblioteki.
Dajmy na to, że w module opakowujesz sobie funkcjonalności jgita. Biblioteka jgit będzie widziana tylko przez ten moduł, reszta ma nie wiedzieć o jego istnieniu w czasie kompilacji (będzie w runtime dependencies).Pokaż całość

@filozofw: pamiętaj jeszcze o elementach gradle dsl - subprojects {} i allprojects {}, tam można oddelegować część odpowiedzialną za wybieranie wersji. Wbrew pozorom, dobrze zorganizowany duży projekt radzi sobie bez sztuczek w wersjonowaniu.
Na ten moment pracowy główny projekt - 300+ modułów, z mavenem już bym się pochlastał. Część logiki powynosiłem do pluginu dołączanego w każdy projekt i tam jest wymuszona konkretna struktura (np pliki z deklaracją bloku dependencies lądują wPokaż całość

@IceBeast: Były jakieś książki na ten temat, ale dotyczą dużo wcześniejszych wersji.

@IceBeast: https://github.com/apache/maven ( ͡° ͜ʖ ͡°)

Taktyczna kropka .

@Bulldogjob: wtyczki do mavena to dramat. Próbowałem zrobić taką większą - nie możesz korzystać z innych wtyczek w swojej, integracja gdy potrzebujesz takiego użycia bo nie chcesz duplikować kody to mieszanka między api mavena 2 lub 3, o dokumentacji teraz się nie wypowiem, ale kilka lat wstecz było bardzo słabo.
Obecnie tworzę wtyczki do Gradle, idealnie nie jest, ale to skok cywilizacyjny.

@egzo2: Jeden, chudszy to JAR aplikacji. Nie ma w nim zależności, tylko to co jest src/, drugi ma suffix fat i posiada wszystkie JARy z zależności <dependencies.... pom-a. Jak sobie rozpakujesz jar-a to zobaczysz różnice.
JAR jest to plik zip, jak masz winblowsa możesz zmienić rozszerzenie na .zip i użyć dowolnego packera. Linux/Mac powinny sobie poradzić z konsoli: zip -d *fat*.jar

Ale ja nie potrzebuję oddzielnej aplikacji (dodatkowo problem dla adminów, bo się komplikują wdrożenia)

@mk321: może czas zmienić adminów, jeśli ogarnięcie frontu i backendu osobno to problem?

@mk321: jak na moje to wystarczy wrzucic fronty do katalogu static w resources i beda serwowane przez serwer z jarki.

Mozesz sobie podpiac zeby podczas budowania mavenem/gradlem odpalal sie jakis webpack (czy co to sie teraz uzywa na rakowych frontach ;p) i jako target mial static

@victordeleco2:
which java
alternatives --config java

Tymi dwoma powyżej zobaczysz co masz włączone i na co możesz się przełączyć. Możesz mieć zainstalowanych wiele wersji, ale tylko jedna - przez Ciebie wybrana - będzie "java".

@kkpol: Jeśli masz Linuksa, to nie potrzebujesz mavena do tego, tylko np. komend find, czy tree.