Nie można zsynchronizować ścieżki klasy Eclipse i Gradle: nie można rozwiązać na typ

Question

Mamy frustrujący problem z naszym obszarem roboczym Eclipse. Oto przykład na wysokim poziomie, co się dzieje:

Projecta
- src/main/java/...
- build.gradle

ProjectB
- src/main/java/...
- build.gradle

Po uruchomieniu gradle eclipse i importowanie projektów do Eclipse, od czasu do czasu dostanie „MyType nie mogą być rozwiązane na typ”, mimo że spełnione są następujące warunki:

• Nasze projekty mają pojemnik biblioteki Gradle na ich ścieżce klasy
• Projekty mają odpowiednie projekty obszaru roboczego w obrębie ich kontenera Gradle
• miejsca jak CTRL + kliknięcie pracę z typów, które są wyświetlane z czerwonym podkreśleniem (to znaczy błąd kompilacji) czyli Eclipse dokładnie wie, jak dostać się do tych typów, ale kompilator nie może ich znaleźć
• wiersza polecenia Gradle buduje pracy zgodnie z oczekiwaniami

To się dzieje w całym zespołem i nie możemy dowiedzieć się, dlaczego Eclipse wciąż nie jest zsynchronizowany i od czasu do czasu nie może się kompilować. Co zwykle rozwiązuje problem jest kombinacją:

• Project> Clean w Eclipse
• Gradle cleanEclipse lub Gradle zaćmienie
• ponownego importowania projektów
• itp

Inne uwagi:

• Używanie programu Gradle w wersji 2.2.1
• Happens zarówno Eclipse i Eclipse Luna Mars
• Korzystanie JDK 8

Czy ktoś miał tego typu problemów w Eclipse kompilacji z projektów Gradle?

Answer 1

Jednym ze źródeł takich problemów może być umożliwienie Gradle generowania metadanych/plików instalacyjnych projektu Eclipse (co otrzymujesz, uruchamiając gradle eclipse). Wiem, że zespoły Maven i Gradle naprawdę chcą, aby ich narzędzie (Maven lub Gradle) generowało te rzeczy, ale notorycznie wykonują go mniej niż idealna praca. Na przykład, po ostatnim użyciu Gradle skonfigurował ścieżkę .classpath do użycia zakodowanej ścieżki biblioteki JRE zamiast preferowanego środowiska wykonawczego. Taka słaba praca przy generowaniu plików powoduje problemy z programistami.

Zamiast tego, zaleceniem Eclipse jest ręczne konfigurowanie projektów (w przeważającej części), pozwalając tylko Gradle zarządzać kontem Classpath, a następnie sprawdzanie w plikach/folderach Eclipse .project, .classpath i .settings. SCM (svn, git, itp.).W ten sposób proces sprawdzania projektu w obszarze roboczym jest automatyczny i nie wymaga ciągłego przeprowadzania gradle eclipse lub mvn eclipse:eclipse.

To jest sposób, w jaki projekty Eclipse zostały pierwotnie zaprojektowane i przeznaczone do zarządzania i działa bardzo dobrze. Pracowałem z takimi konfiguracjami w bardzo dużych projektach (ponad 100 oddzielnych projektów w Eclipse i kilkudziesięciu programistów). Zmniejsza również liczbę kroków, aby przejść od zera do uruchomionej aplikacji.

Jest to jedna z tych filozoficznych różnic między Maven/Gradle i Eclipse; jeśli chodzi o to, IMO, IDE powinno zarządzać swoimi sprawami, a narzędzie do budowania/zależności powinno pozostać na uboczu.

Spróbuj ręcznie dokonać poprawek w konfiguracji projektu, a następnie sprawdź w tych plikach - sprawdź, czy nie zmniejsza to problemów, z którymi boryka się Twój zespół w tym obszarze.