Subversion w Eclipse Ganymede

[Ris]

Witam,
Znalazłem krótką notkę jak podpiąć się pod projekt z poziomu
najnowszej wersji Eclipse Ganymede http://blog.darekzon.com/2008/06/subversion-w-eclipse-ganymede/
Utworzyłem na razie jakiś testowy projekt do zabawy z Subversion.

--
Robert Sajdok (Ris)

[jacek.spolnik]

Aby sie zalogować w Eclipse <instalujemy plugina z powyższego
linka;)> :
-- przechodzimy do widoku SVN Repository Exploring <Window->Open
Perspective->Other>
-- po pojawieniu sie nowego widoku, klikamy na lewej czesci okna <SVN
Respository> prawym przyciskiem i dajemy new-> Repository Location
-- w URL wpisujemy https://linuxadvices.googlecode.com/svn/trunk/ albo
https://linuxadvices.googlecode.com/svn/ <chyba tez dziala, nie
sprawdzalem:P>
-- w user wpisujemy login z code.google.com !! nie z gmaila ;)
-- to samo tyczy się hasla, haslo mozemy odnalezc w Settings <u gory
na prawo;)> gdy jestesmy na stronie projektu

Nastepnie dajemy finish i powinno działać ;)

Pozdrawiam,
Jacek ;)

On Jul 13, 11:38 am, Ris <robert.saj...@gmail.com> wrote:
> Witam,
> Znalazłem krótką notkę jak podpiąć się pod projekt z poziomu

> najnowszej wersji Eclipse Ganymedehttp://blog.darekzon.com/2008/06/subversion-w-eclipse-ganymede/

[pikson]

Witam,

zaciągnąłem kod z repozytorium i mam kilka uwag.
Wydaje mi się, że od samego początku powinniśmy się trzymać pewnego
porządku w repozytorium, żeby póżniej łatwo móc dodawać projekty itp.
Nie wiem jakie i ile będzie przyszłych wersji, więc należało by
zmienić troszkę strukturę w repo.
Piszę o tym dla tego, że jeszcze nie został zrobiony żaden import
(nie wliczam tego testowego :) )

Ja proponuje następującą strukturę:

https://linuxadvices.googlecode.com/svn:
-projektJeden
-trunk
"zawartość projektu"
-branches
-projekt Dwa( tutaj dodajemy np Struts)
-trunk
"zawartość projektu"
-branches

Dzięki temu będzie można w jednym repozytorium be problemu trzymać
kilka projektów
Checkout dwóch projektów:

https://linuxadvices.googlecode.com/svn/projektjeden/trunk
https://linuxadvices.googlecode.com/svn/projektdwa/trunk

Wtedy każda nowa wersja będzie nowym projektem i będziemy mogli
zawsze sobie porównać jak to było w samych servletach :)

Pamiętajmy, że przydodawaniu nowego projektu wszystko powinno
znajdować się w katalogu trunk.

BTW Czy będzie organizowane jakieś spotkanie uczestników projeku? Ja
przez kolejne 2,5 miesiąca jestem w Niemczech, dlatego wolałbym żeby
komunikować się skutecznie tylko przez listę.

BTW 2 Czy w pierwszej wersji będzie używany Ant, czy Maven?

Pozdrawiam
Tomasz Trela

[pikson]

oczywiście nazwy "projektjeden" itp. są tylko takie przykładowe,
należało by dobrać bardziej odpowiednie, opisujące co jest projekcie
vJspServletsAnt lbo jakieś inne.
org.java.linuxadvancies.JspServlets

Pozdrawiam
Tomasz Trela

[Robert Sajdok]

Witam,

2008/7/13 pikson <pikso...@gmail.com>:

Witam,

zaciągnąłem kod z repozytorium i mam kilka uwag.
Wydaje mi się, że od samego początku powinniśmy się trzymać pewnego
porządku w repozytorium, żeby póżniej łatwo móc dodawać projekty itp.

Oczywiście, na razie stworzyłem projekt do poznania mechanizmu Eclipse Ganymede + SVN + hosting google.
 

Nie wiem jakie i ile będzie przyszłych wersji, więc należało by
zmienić troszkę strukturę w repo.

Zgadzam się
 

Piszę o tym dla tego, że jeszcze nie został zrobiony żaden import
(nie wliczam tego testowego :) )

Ja proponuje następującą strukturę:

https://linuxadvices.googlecode.com/svn:
       -projektJeden
               -trunk
                       "zawartość projektu"
               -branches
       -projekt Dwa( tutaj dodajemy np Struts)
               -trunk
                       "zawartość projektu"
               -branches

Podoba się mi ta struktura, poczekajmy jednak może ktoś wypowie się jeszcze w tej kwestii.
 

Dzięki temu będzie można w jednym repozytorium be problemu trzymać
kilka projektów
Checkout dwóch projektów:

https://linuxadvices.googlecode.com/svn/projektjeden/trunk
https://linuxadvices.googlecode.com/svn/projektdwa/trunk

Wtedy każda nowa wersja będzie nowym projektem i będziemy mogli
zawsze sobie porównać jak to było w samych servletach :)

Pamiętajmy, że przydodawaniu nowego projektu wszystko powinno
znajdować się w katalogu trunk.

Popieram. Można będzie też dodać małe projekciki testowe, itp.
 

BTW Czy będzie organizowane jakieś spotkanie uczestników projeku? Ja
przez kolejne 2,5 miesiąca jestem w Niemczech, dlatego wolałbym żeby
komunikować się skutecznie tylko przez listę.

Czy będzie prowadzone jakieś spotkanie. Myślałem już nad tym, Jeśli już to w jakimś tam połączeniu z PJUG w Krakowie. Nie sądzę aby spotkanie było tak istotne, że jak ktoś nie przyjedzie to coś straci :) Raczej bym widział spotkanie w celach poznawczych ludzi z projektu, taka luźna atmosfera. Na pewno wszelkie ustalenia będą opisane na grupie.
 

BTW 2 Czy w pierwszej wersji będzie używany Ant, czy Maven?

Nie mam pojęcia co wybrać. Niby Maven jest nowy i na topie ale non stop słyszy się o jego minusach. Kwestia do dogadania.
 

--
Robert Sajdok (Ris)

[Ris]

Popieram pomysł.

--
Robert Sajdok (Ris)

[Michał Pawluk]

Robert Sajdok pisze:

Witam

Mnie się również podoba taki podział na projekty na jednym svn, łatwiej będzie to ogarnąć.
Co do Ant vs Maven to z Anta korzystam z mavena nie korzystałem nigdy i go nie znam.
Z jednej strony fajnie było by go poznać, miał bym jakieś porównanie. Z drugiej strony, skoro ma dużo wad to może lepiej oprzeć się na sprawdzonym Ancie?

Korzystaliście już z Mavena w praktyce?

Pozdrawiam, Michał

[Robert Sajdok]

Witam,
Ja tylko Ant a co do tych minusów to tylko to co wyczytałem, usłyszałem. Może zadamy pytanie na PJUG?

2008/7/13 Michał Pawluk <quen...@poczta.onet.pl>:

--
Robert Sajdok (Ris)

[pikson]

Ja w jednym projekcie korzystałem z Maven'a i myślę że to bardzo dobre narzędzie, ale dla początkujących użytkowników polecałbym bardziej Ant'a. Tu mamy większą kotrolę, np. niektórych może mylić że nie ma plików bibliotek nigdzie, tylko są one zaciągane na żądanie. A w naszym projekcie mamy się nauczyć od podstaw technologii, więc myślę że lepiej nie wybierać za dużo udogodnień.

Pozdrawiam

Tomasz Trela

[Robert Sajdok]

2008/7/14 pikson <pikso...@gmail.com>:

To proponuje  na razie używać ant a w późniejszym czasie Maven.

--
Robert Sajdok (Ris)

[Darek]

On 14 Lip, 12:06, "Robert Sajdok" <robert.saj...@gmail.com> wrote:
> 2008/7/14 pikson <pikson....@gmail.com>:

>
>
> To proponuje  na razie używać ant a w późniejszym czasie Maven.
>

A ja myślę, że powinniśmy się zdecydować od razu na jeden z tych
dwóch. Ponoć maven jest świetny (nie korzystałem). Może i ma błędy ale
Ant też je ma.

Co do wielu projektów w repozytorium to jestem przeciwnikiem. Każde
repozytorium powinno zawierać tylko jeden projekt no ale wiem również
że google code pozwala na jedno repo na projekt, a, że do tego
projektu będą napisane podprogramy to gdzieś trzeba je przechowywać.
Moim zdaniem powinien to być oddzielny folder np "additionals" i tam
trzymać resztę rzeczy.

Ps. a co z sourceforge? dlaczego akurat google code?

[Robert Sajdok]

Witam,

2008/7/14 Darek <dare...@gmail.com>:

On 14 Lip, 12:06, "Robert Sajdok" <robert.saj...@gmail.com> wrote:
> 2008/7/14 pikson <pikson....@gmail.com>:

>
>
> To proponuje  na razie używać ant a w późniejszym czasie Maven.
>

A ja myślę, że powinniśmy się zdecydować od razu  na jeden z tych
dwóch. Ponoć maven jest świetny (nie korzystałem). Może i ma błędy ale
Ant też je ma.

Chyba takie rzeczy będzie trzeba głosować :)
 

Co do wielu projektów w repozytorium to jestem przeciwnikiem. Każde
repozytorium powinno zawierać tylko jeden projekt no ale wiem również
że google code pozwala na jedno repo na projekt, a, że do tego
projektu będą napisane podprogramy to gdzieś trzeba je przechowywać.
Moim zdaniem powinien to być oddzielny folder np "additionals" i tam
trzymać resztę rzeczy.

Ograniczenia google, więc nic się nie da zrobić, za bardzo.
 

Ps. a co z sourceforge? dlaczego akurat google code?

Wydawało mi się, że google code będzie odpowiednie.

--
Robert Sajdok (Ris)

[Daniel Żmuda]

Darek pisze:

> A ja myślę, że powinniśmy się zdecydować od razu na jeden z tych
> dwóch. Ponoć maven jest świetny (nie korzystałem). Może i ma błędy ale
> Ant też je ma.

Primo: moim zdaniem skoro to ma byc poczatkowo projekt poznawczy to nie
warto od razu zaciagac do roboty Mavena bo sie pogubi wiekszosc ludzi,
ktorzy nie korzystali np. z zadnego 'build toola'.

Secundo: maven jest swietny, ale ...
- jak juz wspomnialem jest nieco skomplikowany
- posiada jeszcze sporo bugow (i nie mowcie, ze mniej niz Ant :)

> Co do wielu projektów w repozytorium to jestem przeciwnikiem. Każde
> repozytorium powinno zawierać tylko jeden projekt no ale wiem również
> że google code pozwala na jedno repo na projekt, a, że do tego
> projektu będą napisane podprogramy to gdzieś trzeba je przechowywać.
> Moim zdaniem powinien to być oddzielny folder np "additionals" i tam
> trzymać resztę rzeczy.

Tutaj sie znowu nie zgodze. Wszystko zalezy od podejscia jakie sie chce
stosowac. W takim projekcie jaki my mamy zamiar tworzyc to moim zdaniem
'wsio jedno', a zeby nie utrudniac poczatkow projektu proponuje jedno repo.

Takie cus znalazlem: http://svnbook.red-bean.com/en/1.1/ch05s04.html
:3-5 paragraf.

> Ps. a co z sourceforge? dlaczego akurat google code?

p.s. a co z google code? dlaczego akurat sourceforge? ;-)
> >
>

--
Pozdrawiam,
Daniel Żmuda

[Daniel Żmuda]

Aha bylbym zapomnial. Jak juz robimy taki wypasny projekt to moze
zaciagnac do roboty tez Traca(lub cos podobnego). Wiem, ze google code
zapewnia juz pewien bug tracking, ale moje przygody z Trac'iem byly
naprawde przyjemne.
--
Pozdrawiam,
Daniel Żmuda

[Robert Sajdok]

2008/7/14 Daniel Żmuda <zmuda....@gmail.com>:

Aha bylbym zapomnial. Jak juz robimy taki wypasny projekt to moze
zaciagnac do roboty tez Traca(lub cos podobnego). Wiem, ze google code
zapewnia juz pewien bug tracking, ale moje przygody z Trac'iem byly
naprawde przyjemne.

Witam,
Chyba lepiej by było jak będziemy używać jak najmniej narzędzi.  Skoro google ma tą funkcjonalność to poco komplikować?


--
Robert Sajdok (Ris)

[Daniel Żmuda]

Robert Sajdok pisze:
>
>
> 2008/7/14 Daniel Żmuda <zmuda....@gmail.com
> <mailto:zmuda....@gmail.com>>:

>
>
> Aha bylbym zapomnial. Jak juz robimy taki wypasny projekt to moze
> zaciagnac do roboty tez Traca(lub cos podobnego). Wiem, ze google code
> zapewnia juz pewien bug tracking, ale moje przygody z Trac'iem byly
> naprawde przyjemne.
>
>
> Witam,
> Chyba lepiej by było jak będziemy używać jak najmniej narzędzi. Skoro
> google ma tą funkcjonalność to poco komplikować?

Oki. W takim razie trzeba rozkminic bugtracking na code google.

--
Pozdrawiam,
Daniel Żmuda

[pikson]

Ja rozumiem, że projekt nie oznacza działającej wersji programu, np. Projektu javowego z Netbeans, tylko całe nasze przedsięwzięcie. A nasze przedsięwzięcie ma na celu naukę od podstaw programowania z użyciem różnych technologii. Należy więc założyć, że jak już wszystkim się znudzi pisanie w czystym JSP to będzie przejście do czegoś innego. Czy to ma oznaczać, że zakładamy nowy projekt, z nowym repozytorium? Po co? 

Tak prawdę powiedziawszy to takie podejście nie ma żadnej zalety nad hostowaniem w repozytorium większej ilości projektów. Choćby dla tego, że zawsze można zrezygnować z tego i nie dodawać ostatecznie nic więcej do repoztytorium. Jeśli natomiast repozytorium ma złą strukturę, to z góry się ograniczasz. Oczywiście zawsze można zrobić zmiany, ale wybierzmy najbardziej elastyczne rozwiązanie.

A rożnica w checkoucie

googlecode/svn/trunk

,a

googlecode/svn/org.pjug.linuxadvaices.jsp/trunk

nie jest duża, za to korzyści większe.

Po za tym, w przyszłości nie będziemy przecież każdego modułu EJB trzymać w osobnym projekcie.

A co do Ant'a i Maven'a.

Najważniejsze jest wg mnie, aby jawięcej się nauczyć i najwięcej rozkminić od podstaw. Daltego powinniśmy unikać jak ognia takich rozwiązań:

W eclipsie kliknij prawym, dodaj server i teraz klikasz na projekt i się samo wdraża.

Dobrze by było, aby z przykładów w projekcie, można się było jak najwięcej nauczyć i zrozumieć. Dlatego jeśli ktoś będzie pisał skrypty ant, do budowania JAR'ów WAR'ów i innych to zrozumie po co się korzysta z tego. W Mavenie trzeba za bardzo trzymać się domyślnych ustawień, ale my przecież nie wiemy co to jest :) Przecież się mamy dopiero nauczyć.

Jestem za Ant'em

Pozdrawiam

Tomasz Trela

PS. Mam pewną propozycję. Może pokusimy się o przygotowanie pewnego materiału szkoleniowego. Każdy będzie miał jakieś zadania, myślę, że warto było by aby oprócz suchej dokumentacji zamieszczać pełne opisy rozwiązania. Na wiki każdy fragment byłby dobrze opisany. Tak mogła by powstać baza wiedzy, która byłaby bardzo cennym materiałem dla wszystkich tu zapisanych. I tak naprawdę nie liczyło by się czy ktoś napisze jakieś 100 linijek kodu, ale to że to jest implementacja jakiegoś wzorca projektowego, który w dekomuntacji opisze. Co o tym sądzicie?

[Robert Sajdok]

2008/7/14 pikson <pikso...@gmail.com>:

Oczywiście, nie zalecam używania kreatorów, wszystko będziemy raczej robić ręcznie, też jestem za Antem.
 

Pozdrawiam

Tomasz Trela

PS. Mam pewną propozycję. Może pokusimy się o przygotowanie pewnego materiału szkoleniowego. Każdy będzie miał jakieś zadania, myślę, że warto było by aby oprócz suchej dokumentacji zamieszczać pełne opisy rozwiązania. Na wiki każdy fragment byłby dobrze opisany. Tak mogła by powstać baza wiedzy, która byłaby bardzo cennym materiałem dla wszystkich tu zapisanych. I tak naprawdę nie liczyło by się czy ktoś napisze jakieś 100 linijek kodu, ale to że to jest implementacja jakiegoś wzorca projektowego, który w dekomuntacji opisze. Co o tym sądzicie?

W pełni się zgadzam.

--
Robert Sajdok (Ris)

[SoNiC]

Co do build tool'a to jeżeli każdy ma się czegoś nauczyc to polecam
ANT'a ale jestem za utrzymaniem struktury projektu tak jak to robimy w
Maven, ułatwi nam to migrację z Anta na Mavena w przyszłosci, inne
plusy to:
- XML :P
- łatwa instalacja :P
- wsparcie w postaci plugina do Eclipse :P
- przyjrzenie się takim funkcjom jak np. javac
- odpalanie np. JUnitów
- tworzenie dokumentacji JavaDoc
- ...coś by się jeszcze znalazło :)

Co mnie wkurza?

w przeszłości w każdym projekcie czy to większym czy mniejszym zawsze
musiałem wszystko pisać od nowa..
Najbardziej wkurzające jest to, żę dużo jest pisania do tak
najprostszych czynności jak np. stworzenie JAR'a...
Ale suma sumaru to i tak jest to lepsze narzędzie niż make pod
UNIXEM :P:P:P

On 14 Lip, 18:09, pikson <pikson....@gmail.com> wrote:
> On 2008-07-14, at 16:02, Robert Sajdok wrote:
>
>
>
> > Witam,
>

> > 2008/7/14 Darek <darek....@gmail.com>:

[stallman]

On 14 Lip, 18:09, pikson <pikson....@gmail.com> wrote:

> Ja rozumiem, że projekt nie oznacza działającej wersji programu, np.  
> Projektu javowego z Netbeans, tylko całe nasze przedsięwzięcie. A  
> nasze przedsięwzięcie ma na celu naukę od podstaw programowania z  
> użyciem różnych technologii. Należy więc założyć, że jak już  
> wszystkim się znudzi pisanie w czystym JSP to będzie przejście do  
> czegoś innego. Czy to ma oznaczać, że zakładamy nowy projekt, z nowym  
> repozytorium? Po co?

Takie podejście będzie wymagało dyscypliny developerów w commitlogu -
chcąc nie chcąc będzie trzeba dodać prefix dzięki któremu będziemy
wiedzieli do którego projektu powinien należeć commit.
Poza tym jeśli myślimy o tym projekcie jako szkoleniowym to sądzę że
nie powinno być tak że nagle wszyscy znikną z projektu JSP i nikt tego
nie będzie ruszał. IMO zaczna tam dochodzić nowi ludzie którzy się
zainteresowali i w ramach takiej "szkółki" będą go rozwijać dalej aż
stwierdzą że pora spróbować czegoś nowego o i wtedy dołączą do innych
np. wyznawców wiosny.
Jeśli wszystkie projekty upchniemy o jednego repozytorium to commitlog
będzie zdefragmentowany. Dalej, jeśli będę developerem projektu
początkowego - czemu robiąc checkout mam ściągać wersje które
kompletnie mnie nie dotyczą? Zarządzanie, filtrowanie zmian będzie
łatwiejsze przy wydzielonych repozytoriach.

> Tak prawdę powiedziawszy to takie podejście nie ma żadnej zalety nad  
> hostowaniem w repozytorium większej ilości projektów. Choćby dla  
> tego, że zawsze można zrezygnować z tego i nie dodawać ostatecznie  

> nic więcej do repozytorium. Jeśli natomiast repozytorium ma złą  

> strukturę, to z góry się ograniczasz. Oczywiście zawsze można zrobić  
> zmiany, ale wybierzmy najbardziej elastyczne rozwiązanie.

A czy kolega trzyma także własne dane wszystkie upchane na 1 partycji
której rozmiar jest równy rozmiarowy dysku ? :) Gratuluję jeśli nigdy
się nic nie stało.
Byłbym ostrożny z pakowaniem wszystkich projektów w jedno miejsce -
akurat w Google to bardzo rzadka sytuacja(a nawet jeśli się zdarzy to
nic nie możemy zrobić) to w normalnym życiu uszkodzenie repozytorium
zdarza się. W przypadku tego modelu uszkadza się więcej niż jeden
projekt. Dalej, jeśli komuś poślizgnęły się palce i zacommitował za
dużo (np. dodał katalog zdjęć z komputera) i zażyczyłby sobie
usunięcia tych danych z repozytorium (sytuacja zakładająca że ktoś z
nas ma "fizyczny" dostęp do niego). W przypadku jednego projektu na
repozytorium będzie to łatwiejsze i nie dotknie reszty projektów.
Dalej - optymalniejsze jest to także w tej sytuacji gdy masz
założonego jakiegoś posthooka który dokonuje automatyczneogo deployu
projektu na środowisko testowe. W przypadku jednego projektu jest to
dość proste - przy wielu projektach musisz napisać programik który
wykryje którego projektu dotyczyły zmiany i optymalnie zaaplikuje te
zmiany. A niech zamarzy się osobne środowisko testowe per branch.....

> PS. Mam pewną propozycję. Może pokusimy się o przygotowanie pewnego  
> materiału szkoleniowego. Każdy będzie miał jakieś zadania, myślę, że  
> warto było by aby oprócz suchej dokumentacji zamieszczać pełne opisy  
> rozwiązania. Na wiki każdy fragment byłby dobrze opisany. Tak mogła  
> by powstać baza wiedzy, która byłaby bardzo cennym materiałem dla  
> wszystkich tu zapisanych. I tak naprawdę nie liczyło by się czy ktoś  
> napisze jakieś 100 linijek kodu, ale to że to jest implementacja  
> jakiegoś wzorca projektowego, który w dekomuntacji opisze. Co o tym  
> sądzicie?

Fajny pomysł ale jak to w tym momencie to dzielenie skóry na
niedźwiedziu. Wykonajmy projekt dokumentując go choćby porządnym
javadoc'iem i wtedy będziemy mogli myśleć o materiale szkoleniowym.
Nie mówiąc o tym że musimy nauczyć się właściwych praktyk - bo projekt
każdy sklecić umie.... ;)
Czy w naszym gronie jest ktoś kto już posiada doświadczenie w tego
typu projektach którym mógłby się podzielić?

[pikson]

Na samym początku zaznaczę, że wolałabym nie przeciągać dłużej tego wątku. Nikt nie będzie się tutaj z SVN doktoryzował (chyba).

Właściwie to nie chcę być uszczypliwy, ale naprawdę nie wiem co przemawia za utrudnianiem sobie życia. Ustalmy, w SVN możesz przechowywać dowolną ilość niezależnych projektów! Ściągasz co chcesz i jest to niezależne od innych rzeczy, które są w svn. 

Co to znaczy, że commiting będzie zdefragmentowany?

Jak chcesz to możemy się umówić, że to repozytorium jest na jeden projekt. 

Tylko, że projekt składa się na wiele bibliotek :)

Po prostu jeśli będziemy mieć jakiś super uniwersalny kod to warto go umieścić w innym katalogu nazwać jako inną bibliotękę, budować go osobno i dostarczać do naszej aplikacji jako jar. Tak się czasem robi, szczególnie w projektach open source.

Po za tym aplikcje JEE mogę się skaładać z wielu EJB i to wszystko jest jednym projektem. 

Naprawdę nie przekonasz mnie że łatwiej Ci jest zrobić checkout

https://linuxadvices.googlecode.com/svn/trunk/

zamiast

https://linuxadvices.googlecode.com/svn/projects/linuxadvices-alpha/trunk

Wystarczy dopisanć kilka liter na końcu. Należy wybierać najprostsze rozwiązania, które sa jednocześnie najbardziej wygodne i modyfikowalne w przyszłości.

Obecnie w repozytorium jest:

A    svn/trunk

A    svn/trunk/plikTest.txt

A    svn/wiki

A    svn/wiki/Start.wiki

A    svn/wiki/OpisWymagan.wiki

A    svn/wiki/DodaniePorady.wiki

A    svn/wiki/PracaZsvn.wiki

A    svn/wiki/UruchamanieAplikacji.wiki

A    svn/wiki/OpisArchitektury.wiki

A    svn/.project

A    svn/branches

A    svn/Test Project

A    svn/Test Project/trunk

A    svn/Test Project/branches

A    svn/Test Project/tags

A    svn/src

A    svn/src/Testowa.java

A    svn/src/Tes.java

A    svn/tags

     svn/projects/linuxadvices/trunk/.. - cały projekt

     svn/projects/mojasuperfajnabiblioteka/trunk/.. ktora bedzie mozna pozniej wykorzystac

Na czerwono jest to czego tam nie powinno być, na zielono to co powinno.

W eclipsie robisz checkout na svn/projects/linuxadvices/trunk/ i nic nie musisz się martwić co jest jeszcze w repozytorium.

I to tyle w tej kwestii.

A tak naprawdę to widzę duży zastój w przedsięwzięciu. Niestety nie mam książki Object Oriented Design Head First, ani nie mam Servlets & JSP Head First. 

Zrobiłem zmiany na wiki, proszę o komentarze.

Myślę, że można by podejść troszkę Agile'owo. Wydaje mi się, że powinniśmy zacząć od logowania. Jest to najbardziej popularny problem. Ta funkcjonalność jest zresztą porzebna przy dodawaniu czy komentowaniu porad i nie jest zależna od żadnych innych elementów. Myślę że w sobotę moglibyśmy zacząć kodować, dlatego do soboty można by zrobić dokładniejszy opis co chcemy zrobić.Tzn. jak nasze logowanie ma wyglądać.

Jak będziemy przechowywać id usera itp. Na razie możemy się skupić chyba na tym.

Przed kdowaniem powinniśmy mieć dokładnie rozpisane co i jak chcemy zrobić. A następnie jakoś podzielimy się pracą.

Wogóle wydaje mi się, że najlepiej będzie jeśli najpierw dokładnie opiszemy nasze wymagania. Dzięki temu będziemy mogli jakoś podzielić się pracą. Jeżeli stworzymy dokumentację np. dotyczącą wyświetlania drzewa kategorii, to niezależnie czy ja czy ktowkolwiek inny to zaimplementuje, będziemy mieć to o co nam chodziło, nie to o co mi chodziło. Po za tym uboga dokumentacja doprowadzi do tego, że ten kto to zaimplementował będzie miał rozwiązanie w głowie i dla niego plus, ale przecież większość kawałków będzie pisana przez innych developerów więc warto mieć całą wiedzę w formie dokumentu. 

Pozdrawiam

Tomasz Trela

[Daniel Żmuda]

IMHO przydaloby sie jeszcze chociaz ustalic jakis szkielet bazy danych.
Byc moze jeszcze za wczesnie bo nie mamy do konca ustalonych wymagan,
ale pozniej moga pojawic sie przez to komplikacje.

pikson pisze:

>
> Na samym początku zaznaczę, że wolałabym nie przeciągać dłużej tego
> wątku. Nikt nie będzie się tutaj z SVN doktoryzował (chyba).
> Właściwie to nie chcę być uszczypliwy, ale naprawdę nie wiem co
> przemawia za utrudnianiem sobie życia. Ustalmy, w SVN możesz
> przechowywać dowolną ilość niezależnych projektów! Ściągasz co chcesz i
> jest to niezależne od innych rzeczy, które są w svn.
> Co to znaczy, że commiting będzie zdefragmentowany?
>
>
> Jak chcesz to możemy się umówić, że to repozytorium jest na jeden projekt.
> Tylko, że projekt składa się na wiele bibliotek :)
> Po prostu jeśli będziemy mieć jakiś super uniwersalny kod to warto go
> umieścić w innym katalogu nazwać jako inną bibliotękę, budować go osobno
> i dostarczać do naszej aplikacji jako jar. Tak się czasem robi,
> szczególnie w projektach open source.
>
> Po za tym aplikcje JEE mogę się skaładać z wielu EJB i to wszystko jest
> jednym projektem.
>
> Naprawdę nie przekonasz mnie że łatwiej Ci jest zrobić checkout
>

> */https/*://linuxadvices.googlecode.com/svn/trunk/
>
> zamiast
>
>
> */https/*://linuxadvices.googlecode.com/svn/projects/linuxadvices-alpha/trunk

--
Pozdrawiam,
Daniel Żmuda

[pikson]

On 2008-07-29, at 12:40, Daniel Żmuda wrote:

>
> IMHO przydaloby sie jeszcze chociaz ustalic jakis szkielet bazy
> danych.
> Byc moze jeszcze za wczesnie bo nie mamy do konca ustalonych wymagan,
> ale pozniej moga pojawic sie przez to komplikacje.
>
>

Oczywiście, że tak.

Baza danych powinna być zaprojektowana na podstawie wymagań. Na razie
na wiki jest zarys schematu, tzn. tego co chcemy przechowywać w bazie
danych. Myślę, że skrypt powinien być zgodny z tym co jest na wiki, i
w razie ewoluowania wymagań obydwie rzeczy powinny być update'owane.

Pozdrawiam
Toamasz Trela

[Robert Sajdok]

2008/7/29 pikson <pikso...@gmail.com>

Witam,
Porobiłem porządek w projekcie w związku z dyskutowanymi zmianami.


--
Robert Sajdok (Ris)