Pliki kompilacji NetBeans nigdy nie są poprawne

Question

Mój obecny zespół ustandaryzował NetBeans dla całego naszego rozwoju Java i używamy wygenerowanych przez NetBeans plików ANT jako naszego oficjalnego procesu kompilacji.

Ale pliki są zawsze błędne.

Różni członkowie zespołu używają różnych wersji NetBeans i ewidentnie generują nieco inne pliki "build-impl.xml". Tak więc, po uruchomieniu IDE, NetBeans zregeneruje dowolny z tych plików, które uzna za nieprawidłowe lub nieaktualne.

Ale wtedy (ponieważ te pliki są sprawdzane w formancie źródłowym, jako nasze oficjalne skrypty budujące) pliki kompilacji są zwykle niezsynchronizowane z repozytorium. Jeśli sprawdzę automatycznie wygenerowane zmiany z mojego komputera, to jakiś inny frajer w moim zespole będzie musiał nadpisać własną lokalną kopię skryptów budujących, powodując, że NetBeans złoży skargę, że pliki są nieaktualne i muszą być zregenerowany.

Przeważnie jest to irytujące. Zarówno fałszywe różnice w automatycznie generowanych skryptach budujących dodają wiele szumu do przesiewania za każdym razem, gdy programista wykonuje checkin. Lub IDE stale narzeka na zewnętrzne modyfikacje skryptów budujących. Nie możesz wygrać.

Ale mam też ciągłe dokuczliwe uczucie, że nikt nie ma w pełni poprawnego scenariusza budowy, a my wprowadzamy indeterminizm w cały proces budowy.

O ile mogę powiedzieć, istnieją dwa możliwe rozwiązania tego problemu:

1) standaryzacja na konkretnej wersji NetBeans. Nie pozwalaj ludziom na aktualizację, dopóki nie podejmiemy decyzji, jako zespół, aby to zrobić. I nie pozwól, aby ludzie przechodzili z tyłu w starych wersjach. Jeśli wszyscy w drużynie używają tej samej wersji NB, wtedy te problemy (prawdopodobnie) znikną.

2) Nie zaznaczaj skryptu "build-impl.xml" w kontroli kodu źródłowego. Jest automatycznie generowany przez IDE i dlatego jest artefaktem plików "build.xml" i "project.xml". Wygenerowane pliki (takie jak pliki ".class") nie powinny być sprawdzane pod kontrolą źródła, ale powinny być ponownie generowane podczas procesu kompilacji. Sprawdź, jaki mechanizm wykorzystuje NetBeans do wygenerowania pliku "build-impl.xml" i uruchom ten sam mechanizm na naszym serwerze kompilacji. Czy to oznacza, że ​​nasz serwer kompilacji musiałby polegać na GUI NetBeans? Mam nadzieję, że nie.

Co wy myślicie? Jaki jest właściwy sposób rozwiązania tego problemu?

Answer 1

myślę, należy udać się do numeru 1, mają wszystkie zespołu używać tej samej wersji NetBeans. W mojej pracy rozwijamy się także w NetBeans, ale wszyscy używamy tej samej wersji i aktualizujemy w tym samym czasie. Przez ostatnie dwa lata używałem NetBeans, doświadczyłem, że różne rzeczy zmieniają się z każdym wydaniem (mniej obecnie), od konfiguracji do plików formularzy, więc czuję, że lepiej jest zminimalizować potencjalne problemy z różnymi wersjami.

Łatwiej jest też wskazać źródło błędu, jeśli wszyscy mają takie samo środowisko.

Answer 2

Co powiesz na użycie wersji build-imp.xml.template, która wersjonuje i ignoruje plik build-imp.xml dotyczący kontroli źródła. Użytkownicy mogą "łatwo" połączyć swoje "osobiste" pliki kompilacji z wersjonowanymi. Możliwość propagowania zmian za pośrednictwem "build-imp.xml.template" do ich współpracowników.

Możesz odszukać Understand MacroDef Tasks in Netbeans Build Files.

Answer 3

Według moim zdaniem następujące foldery nie mogą być dodawane do kontroli źródła:

1. budowy (który zawiera pliki .class)
2. dist (który zawiera wbudowane pliki JAR)
3. nbproject/prywatne (chociaż zawiera lokalne pliki specyficzne dla maszyny)

Nie zobowiązujemy się.pliki klas, w zasadzie wszystko, co zostanie wygenerowane z procesu budowania NetBeans do repozytorium kontroli kodu źródłowego.

Wszystkie lokalne dostosowania należy wykonać w pliku build.xml przechowywanym w katalogu głównym projektu, a dostosowania, jeśli są one przeznaczone dla programisty, nie będą ponownie zatwierdzane do repozytorium. Plik nbproject/build-impl.xml nie zostanie dotknięty raz utworzony przez generator projektu NetBeans.

odniesieniu Tushar