@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 zPokaż całość

@alex-fortune: jeśli chodzi o języki:

C++: tu było całkiem dobrze, bo C++ ma na tyle prostacki i zły system budowania, że Bazel z automatu staję się przejściem w XXI wiek. Szybkie czasy kompilacji, trzymanie developerów za mordę (żeby nie wymyślali głupich rozwiązań) i budowanie wszystkiego ze źródeł to super zalety w porównaniu do popularnego CMake. Było dużo problemów z pierdołami typu ktoś w googlu uznał, że pliki .cpp będzie się budowało poprzez komendę gcc (zamiast g++), co w 99% działa a w 1% trzeba się bawić. Albo nie damy wsparcia dla precompiled headers, bo w googlu tego nie używamy, zamiast tego możesz użyć clangowych modułów, które używane są tylko w googlu

Python: słabo, domyślny support nie ma wsparcia dla pipa (bo w googlu nie używają). Pamiętam, że wybór odpowiedniego interpretera był słabo rozwiązany, choć teraz jak patrzyłem ostatnio na githubowy rules_python jest coraz lepiej (https://github.com/bazelbuild/rules_python#toolchain-registration , w sumie to ważny plus, że roku na rok jest DUŻO lepiej). No i wsparcie dla IDE: Pycharm nie ogarniał kompletnie zależności pobranych z pipa (bo w googlu nie używają) przez co na dobrą sprawę wsparcia nie było
Java: tu było w miarę dobrze. Oczywiście były problemy jak ktoś użył jakiegoś fikuśnego pluginu do mavena,Pokaż całość

@pyroxar: tak jak mówi @acpiorundc: użyj groovy a nie kotlina do pisania w pliku build.gradle

@joolekk: @pyroxar: jakby co to w gradle piszesz albo w groovy ( bez kts. czyli build.gradle ) albo w kotlinie i wtedy plik ma nazwę (z kts czyli build.gradle.kts ) i dlatego może jak kopiowałeś example to pokopoiwałeś część z groovy a część z kotlina i nie działa.

@Rubajticos: a to nie jest przypadkiem tak, że wartości z vault są w logu nadpisywane gwiazdkami, ale w rzeczywistości są podawane poprawne wartości?

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

@novak00: w praktyce wszyscy będą na ciebie k----ć :D
Możesz sobie zrobić kopię artefaktów potrzebnych do budowania/uruchamiania konkretnej wersji aplikacji, ale w dużej skali to jest ból d--y. 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.Pokaż całość

@herbatkaZCukremBezCytrynki: https://github.com/heroku/heroku-gradle
heroku {
processTypes(
web: "java -jar build/libs/my-app.jar"
)
}

spróbuj compile zmienic na implementation

@kezioezio: Gradle zmieniło swoją konfigurację zależności z podobnej do maven-a do swojej np compile zmieniło się na compileOnly. Więcej będziesz miał w dokumentacji gradle
Sprawdź czy próbujesz dodać zależności w bloku dependencies {} i upewnij się, że sam blok dependencies jest w odpowiednim bloku.

@BrakWolnegoLoginu gradle nie jest jesce supportowwny do tej Javy. Jak na studia, to weź to odpal na javie 8 czy tam 11.

@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). Jak ktoś w życiu widział OSGi, to podejście wyda mu się naturalne (Import-Package)

2. Nie powinno się hardkodować wszystkich zależności w projekcie. Dopiero kiedy wychodzi jakiś konflikt, można dać wskazówki do gradle, jak powinienPokaż 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ąPokaż całość

@Dominias: sprawdź wersję gradle. w pewnym momencie "compile" zamieniono na "implementation" oraz "api"

@another_throwaway23: compile jeszcze działa, ale jest deprecated. Po prostu implementation/compile to funkcja, a zgodnie ze składnią kotlina nie można oddzielić argumentów funkcji średnikiem. Tak samo przy nazwanych argumentach stosuje się znak =. Ma to sens kiedy podajemy argumenty w innej niż domyślna kolejności.

@Masilt: pewnie nie masz konferencji w build.gradle https://docs.microsoft.com/en-us/azure/devops/artifacts/gradle/publish-package-gradle?view=vsts&tabs

@Masilt: wygląda na to że się nie zdeployowała. Niestety nie powiem ci jak to dokładnie działa bo ja pracuję z kontenerami i AKSem

@suluat: nic nie rozumiem xD

@AndroidKuc: nie kumam? To jak on liczy pokrycie? Po wywołaniach metod, czy przy przejściu przez dany fragment?

@luuzik: jeśli masz wszystkie wymagane elementy, to obstawialbym, że klasa opisana jako springapplication jest w głównym katalogu kodu a nie w pakiecie