Solucja i projekt to nie to samo. A w Eclipse jest coś podobnego do solucji? Czy tez uznano to za niepotrzebne?
0
0
A co to jest solucja? W Eclipse są workspaces grupujące projekty, a w NetBeansie jest coś takiego jak Project Group.
0
othello napisał(a)
Solucja i projekt to nie to samo. A w Eclipse jest coś podobnego do solucji? Czy tez uznano to za niepotrzebne?
Tak wiem ze to co innego dlatego napisalem oba sposoby uzywajac slasha do rozdzielenia. No ale po raz kolejny napisalem bez skladu, sory za to.
Solucji w Eclipse / NB nie ma. Nie uzywam NB za duzo, wiec opisze jak uzywam Eclipse. Mozna miec tam wiele workspacow ktore grupuja projekty. Jak juz sie projekty zaimportuje (mozna kilka na raz), poustawia im ustawienia (czasami trzeba np. zmieniac sciezki do javy itp - wynika to z tego ze jednak separacja IDE od JVM jest wieksza niz VS od .NET, oraz ze VS musi sie integrowac z raptem 1 (rodzina) OS, ale moze sie myle i jest to w Eclipse po prostu do d**y?) to jest w workspace i juz. Mozna miec nieskonczenie wiele workspace, i przy starcie mozna wybrac na jakim sie chce pracowac. Mozna miec kilka eclipsow i robic w kilku workspace - ale kto ma tyle RAM ;d
Prawde mowiac moje ostatnie podrygi w .NET to byl rok jakis 2008 i chyba VS 2005, ale w wielu kwestiach dzisiejszy Eclipse jest 100 lat za Murzynami. Sam VS plus Re-sharper (czy jakos tak) wtedy byl calkiem przyjemnym narzedziem, a od znajomych .NET-owcow wiem ze 2010 to juz nie byle co.
0
Można też zmieniać workspace poprzez Switch workspace.
Po co w ogóle są te solucje? To jest jedna z rzeczy, która mnie denerwowała, gdy musiałem robić projekt w VS.
0
Wibowit napisał(a)
Można też zmieniać workspace poprzez Switch workspace.
Switch workspace jest ... ekhm ... kiepskim porownaniem. Startujesz eclipse z jakims domyslnym workspace, tam moga byc projekty mavenowe np, pelno budowania, pelno odswiezania projektow itp itd, jakies kompilacje na starcie, itp itd, po czym klikasz Switch Workspace i eclipse startuje jakby od nowa. Swietnie!
Wibowit napisał(a)
Po co w ogóle są te solucje? To jest jedna z rzeczy, która mnie denerwowała, gdy musiałem robić projekt w VS.
Solucje grupuja projekty w (nie)logiczna / (nie)funkcjonalna jednostke (zalezy od programisty ;d). Przenosisz projekty na innego kompa, dwuklik na solucje i sie otwiera VS z tymi projektami. Zadnego importowania czy cos.
Dla porownania, mamy projekt z 12 modulami w eclipse. Ile sie trzeba naje8ac aby to zaimportowac... Fakt nie robisz tego codziennie, ale jak musisz zrobic to jest to porazka.
To ze czegos nie rozumiesz nie znaczy ze jest zle i ze masz sie tym denerwowac.
Pytanie do uzytkownikow VS - jakich systemow kontroli wersji uzywacie? Jakies zintegrowane czy cokolwiek co sie w tej chwili uzywa (hg, bzr, git, svn, ...)? Sa jakies wtyczki do tego, czy TortoiseHG i jazda? Wersjonujecie pliki projektowe / solucji?
0
othello napisał(a)
A po co opcja otwierania projektu? Projekt trzeba utworzyć, skompilować, oddać do klienta i zapomnieć. Nie wraca się do starych projektów. Tylko lamerzy zamkyają IDE przed ukończeniem projektu.
W sumie możliwe. Wynikałoby z tego, że Eclipse służy do pisania HelloWorldów.
bo napisał(a)
Otwierałem dziesiątki projektów (stworzone kiedyś przez Eclipse, skopiowane z nie wiadomo skąd, tworzone "ręcznie" bez żadnego IDE): Create=>Java Project=>Create project from existing source. Czemu tak nie działasz?
Ja Ci ufam i wierzę, że tak powinno się robić. Ale nie działam tak, bo nie mam takiej możliwości. Nie mam w menu nawet opcji "Create", jest tylko "New", jeśli tam wybiorę "Java Project", to nie mam żadnej opcji podobnej do "from existing source".
Poza tym, muućka twierdzi coś innego. Skąd taka różnica?
Wibowit napisał(a)
Po co w ogóle są te solucje? To jest jedna z rzeczy, która mnie denerwowała, gdy musiałem robić projekt w VS.
Pewno po to, po co są workspace. Solution (po angielsku zdaje się "rozwiązanie") to po prostu grupa projektów realizowana razem. W ramach solution tworzy się np. projekt będący interfejsem użytkownika, zestaw bibliotek realizujących logikę aplikacji oraz pomocnicze narzędzia konsolowe, itd.
muućka napisał(a)
Prawy klik na liscie projejktow -> Import -> wybierasz existing java project lub np existing maven project czy inne -> dalej postepujesz zgodnie z wizardem.
I tak właśnie udało mi się to zrobić, z tym że po drodze muszę jeszcze zaznaczyć opcję skopiowania importowanego projektu do workspace.
Wnioski z moich badań są następujące:
- Eclipse to jedyne IDE nie posiadające jednoznacznej opcji otwierania projektu. Jest to nieintuicyjne - każdy program "produkujący" jakieś pliki powinien potrafić je otwierać. Tak robią edytory tekstów, arkusze kalkulacyjne, programy graficzne i wszystkie inne IDE. Każdy taki program posiada opcje "File -> Open *".
- "Otwieranie" poprzez import jest nieintuicyjne. Importowanie to wczytywanie do programu czegoś, co nie powstało w nim. Np. GIMP mógłby importować pliki Photoshopa, a CodeBlocks projekty Dev-C++ (to chyba nawet robi). Importowane jest coś OBCEGO. Nie rozumiem dlaczego projekt Eclipse jest dla Eclipse czymś obcym?
- Eclipse, w przeciwieństwie do wszystkich innych IDE nie pozwala na otwarcie i pracę na projekcie znajdującym się w DOWOLNYM miejscu na dysku. Nie można pracować bez workspace i wszystkie projekty muszą się znajdować w katalogu tegoż workspace. Z tego właściwie wynikał mój problem - z przyzwyczajenia do wolności pracy, którą daje każde inne IDE.
0
Solucje grupuja projekty w (nie)logiczna / (nie)funkcjonalna jednostke (zalezy od programisty ;d). Przenosisz projekty na innego kompa, dwuklik na solucje i sie otwiera VS z tymi projektami. Zadnego importowania czy cos.
Dla porownania, mamy projekt z 12 modulami w eclipse. Ile sie trzeba naje8ac aby to zaimportowac... Fakt nie robisz tego codziennie, ale jak musisz zrobic to jest to porazka.
No to przecież w Eclipse są workspaces (i wystarczy, że skopiuję cały folder z workspacem, włącznie z plikami ukrytymi Eclipsa, i mogę sobie potem wszystko naraz otworzyć bez żadnego importowania), a w NetBeans są Project Groups oraz np opcja Open Required Projects czy jakoś tak.
Nie wytłumaczyliście dlaczego wg was solucje z VS są lepsze od rozwiązań z Eclipse czy NetBeans i nie wytłumaczyliście mi również czemu importujecie projekt Eclipsowy do Eclipsa zamiast po prostu otworzyć workspace.
0
somekind napisał(a)
muućka napisał(a)
Prawy klik na liscie projejktow -> Import -> wybierasz existing java project lub np existing maven project czy inne -> dalej postepujesz zgodnie z wizardem.
I tak właśnie udało mi się to zrobić, z tym że po drodze muszę jeszcze zaznaczyć opcję skopiowania importowanego projektu do workspace.
Cieszy mnie to. Ale kopiowac do workspace wcale nie musisz.
somekind napisał(a)
Wnioski z moich badań są następujące:
- Eclipse to jedyne IDE nie posiadające jednoznacznej opcji otwierania projektu. Jest to nieintuicyjne - każdy program "produkujący" jakieś pliki powinien potrafić je otwierać. Tak robią edytory tekstów, arkusze kalkulacyjne, programy graficzne i wszystkie inne IDE. Każdy taki program posiada opcje "File -> Open *".
Zgadzam sie w 100%. Tym smieszniej, ze eclipse robi jakies swoje ukryte pliki (chocby .project) wiec moglby umiec otworzyc projekt na dwuklik - a nie umie.
somekind napisał(a)
- "Otwieranie" poprzez import jest nieintuicyjne. Importowanie to wczytywanie do programu czegoś, co nie powstało w nim. Np. GIMP mógłby importować pliki Photoshopa, a CodeBlocks projekty Dev-C++ (to chyba nawet robi). Importowane jest coś OBCEGO. Nie rozumiem dlaczego projekt Eclipse jest dla Eclipse czymś obcym?
I ja nie rozumiem.
somekind napisał(a)
- Eclipse, w przeciwieństwie do wszystkich innych IDE nie pozwala na otwarcie i pracę na projekcie znajdującym się w DOWOLNYM miejscu na dysku. Nie można pracować bez workspace i wszystkie projekty muszą się znajdować w katalogu tegoż workspace. Z tego właściwie wynikał mój problem - z przyzwyczajenia do wolności pracy, którą daje każde inne IDE.
To jest nieprawda. Eclipse wymaga zawsze workspace, ale moze on byc pusty, i skladowac jedynie metadane / ustawienia (jak np servery aplikacji, jakies ustawienia wtyczek itp) w podkatalogu .metadata. Wszystko inne podczas importowania mozna zostawic w innych, dowolnych miejscach. Tutaj nie masz kompletnie racji. Mozliwe ze to ze nie udalo Ci sie importowac bez kopiowania wynika z ogolnie znanej stabilnosci Eclipse? Mi sie jednak udaje.
0
Mozna miec kilka eclipsow i robic w kilku workspace - ale kto ma tyle RAM ;d
Haha, no to VS rządzi :P
Codziennie pracuję na przynajmniej 4-5 jednocześnie otwartych VS (z różnymi solucjami) i wszystko ładnie działa, chociaż kompa mam nienajnowszego (2GB RAM).
0
Wibowit napisał(a)
Solucje grupuja projekty w (nie)logiczna / (nie)funkcjonalna jednostke (zalezy od programisty ;d). Przenosisz projekty na innego kompa, dwuklik na solucje i sie otwiera VS z tymi projektami. Zadnego importowania czy cos.
Dla porownania, mamy projekt z 12 modulami w eclipse. Ile sie trzeba naje8ac aby to zaimportowac... Fakt nie robisz tego codziennie, ale jak musisz zrobic to jest to porazka.No to przecież w Eclipse są workspaces (i wystarczy, że skopiuję cały folder z workspacem, włącznie z plikami ukrytymi Eclipsa, i mogę sobie potem wszystko naraz otworzyć bez żadnego importowania), a w NetBeans są Project Groups oraz np opcja Open Required Projects czy jakoś tak.
No to zwersjonuj sobie caly workapces z calym badziewiem ktory tam w srodku siedzi (wersjonujesz pliki .project, .classpath, i caly shit z .metadata? gratulacje). Ponadto, taki spakowany i przeniesiony workspace najczesciej nie umie poradzic sobie z upgrade eclipsa - inne pluginy, inne podkatalogi w .metadata, skladnia plikow, wartosci parametrow w .classpath czy tam .project... Koszmar. Przenies to na inny system - to samo.
Wibowit napisał(a)
Nie wytłumaczyliście dlaczego wg was solucje z VS są lepsze od rozwiązań z Eclipse czy NetBeans i nie wytłumaczyliście mi również czemu importujecie projekt Eclipsowy do Eclipsa zamiast po prostu otworzyć workspace.
Bo czasami trzeba umiec otworzyc projekt bez workspace? Nie powiedziales nam dlaczego NIE masz nigdy projektow bez workspace - ale sadzac po tym ze podales zly sposob na import projektu do eclipse masz pewnie bardzo male doswiadczenie, wiec jest Ci to wybaczone.
Pierwszy lepszy przyklad - repozytorium kodu, 12 modulow mavenowych, kazdy wersjonuje tylko src/*, pom.xml oraz .hgignore (mercurial), i zadnego szajsu eclipsowego. Ja pisze w eclipse, kolega w NB, a kolezanka w IDEA. Kazdy z nas podczas rozpoczacia pracy musi zaimportowac te projekty.
Stad tez moje pytanie do VS-userow - czy wersjonuja te pliki VS? Jako ze VS jest jeden, i to tylko pod Windowsa, jestem sklonny stwierdzic ze bym sie posunal do takiego rozwiazania, ale mozliwe ze to calkowicie zle podejscie?
Jesli nie widzisz roznicy w starcie eclipse (godzina czasu, kawka, pogaduszki) i zmianie workspace (kolejny start eclipse, juz pora obiadowa) a dwukliku na plik solucji i otwarciu projektow do niej nalezacej, to a) jestes zielony i dopiero zaczynasz prace i nie wiesz jeszcze ile to moze trwac w eclipse b) lubisz sobie utrudniac.
Ja osobiscie uzywam Eclipse, ale wiem ze nie jest to pepek swiata - sa IDE o lepiej rozwiazanych sprawach tu i owdzie.
PS. Wiem ze nie jestes zielony i "sie znasz", mowie tak zeby cie podgrzac bo to flame. Ale prawde mowiac to co piszesz brzmi bardzo naiwnie.
0
aurel napisał(a)
Mozna miec kilka eclipsow i robic w kilku workspace - ale kto ma tyle RAM ;d
Haha, no to VS rządzi :P
Codziennie pracuję na przynajmniej 4-5 jednocześnie otwartych VS (z różnymi solucjami) i wszystko ładnie działa, chociaż kompa mam nienajnowszego (2GB RAM).
Mozna lepiej - mozna miec menu np Eclipse, a pod nim wiele 'konfiguracji startowych' wolajacych eclipse z -workspace 'c:/wibovit/mojpierwszyworkspace' itp itd. Super.
Nie ma co, pod tym wzgledem (moim skromnym zdanem) eclipse lezy. Ma za to wiele wiecej innych zalet i przewag.
0
mućla napisał(a)
No to zwersjonuj sobie caly workapces z calym badziewiem ktory tam w srodku siedzi (wersjonujesz pliki .project, .classpath, i caly shit z .metadata? gratulacje). Ponadto, taki spakowany i przeniesiony workspace najczesciej nie umie poradzic sobie z upgrade eclipsa - inne pluginy, inne podkatalogi w .metadata, skladnia plikow, wartosci parametrow w .classpath czy tam .project... Koszmar. Przenies to na inny system - to samo.
Dodam tylko ze VS 2005 lub 2008 to byla ostatnia wersja jakiej uzywalem, nie wiem jaka jest teraz, ale bylo kilka wczesniejszych - do C++, jakichs FoxPro itp. Przenoszenie projektow i import odbywal sie zawsze tak samo - dwuklik na plik projektu, otwieral sie VS, mowil ze costam costam nowa wersja, importujemy, zapisujemy w nowym formacie i jechane - dzialalo.
0
Prawdę mówiąc to nie trawię Eclipse i go nie używam prawie :P Zbyt przekombinowany jak dla mnie. Wolę NetBeans - proste jak budowa cepa, acz funkcjonalne.
Jeśli chodzi o NetBeans to przy wersjonowaniu można przecież ignorować foldery. Tylko chyba trzeba to zrobić przed pierwszym commitem. Robiłem wersjonowany projekt w NetBeans i nie wersjonowałem NetBeansowych "śmieci". Choć w sumie nie widzę problemu, aby te pliki NetBeansowe wersjonować (oprócz folderów prywatnych). W końcu projekt ma jakąś tam konfigurację i czasem mogłoby być przydatne wersjonowanie konfiguracji.
0
czy wersjonuja te pliki VS? Jako ze VS jest jeden, i to tylko pod Windowsa, jestem sklonny stwierdzic ze bym sie posunal do takiego rozwiazania, ale mozliwe ze to calkowicie zle podejscie?
Ja wersjonuję plik sln. Nie wersjonuję pliku .suo, ponieważ tworzy się on przy każdej kompilacji i po pierwsze z tego względu nie trzeba, po drugie zbyt często się zmienia by go wersjonować.
Sln się zmieni jak np. dodasz nowy projekt do solucji - wtedy wersjonowanie się przydaje, następna osoba, która otworzy solucję od razu też będzie miała dodany nowy projekt.
0
Wibowit napisał(a)
Prawdę mówiąc to nie trawię Eclipse i go nie używam prawie :P Zbyt przekombinowany jak dla mnie. Wolę NetBeans - proste jak budowa cepa, acz funkcjonalne.
Oj bo sie Cepa obrazi. Chociaz moze nie...
Wibowit napisał(a)
Jeśli chodzi o NetBeans to przy wersjonowaniu można przecież ignorować foldery. Tylko chyba trzeba to zrobić przed pierwszym commitem. Robiłem wersjonowany projekt w NetBeans i nie wersjonowałem NetBeansowych "śmieci". Choć w sumie nie widzę problemu, aby te pliki NetBeansowe wersjonować (oprócz folderów prywatnych). W końcu projekt ma jakąś tam konfigurację i czasem mogłoby być przydatne wersjonowanie konfiguracji.
No to teraz otworz czysty nowy netbeans, gdzie workspace czy tam project group jest pusty, sciagnij te 'czyste' projekty bez netbeansowych 'smieci' i po prostu je otworz i zacznij kodowac. Jak masz szczescie to wtyczka do twojego (D)VCS pozwala na taki zabieg, zdaje sie ze Mercurialowy plugin to umie. W Eclipse niby umie ale nie umie - wywala sie czesciej niz dzialal (a moze raczej wywalal - od jakiegos czasu nie robilem tego, moze sie poprawilo).
Co do NB - uzywasz mavena? Jak tam wyglada integracja? Ja z kazda nowa wersja NB (ostatnio z 7.0) biore nasze projekty i probuje importowac, i patrze jak wyglada wspolpraca NB i mavena. Obecnie to porazka - NB po prostu wola polecenia mvn - integracji nie ma zadnej. Dla porownania, m2eclipse umie zarzadzac classpath, pom.xml, a jak zrobie sobie run config zeby jechal z testami (TestNG, maven3, EJB embedded i cokolwiek) to jest startuje jakby 'wewnetrznie' - ale classpath brany z mavena, jest to proces eclipsowy wiec moge ladnie debugowac itp. W NB odpalany jest proces mvn wiec wez debuguj te testy. Dla mnie wlasnie ta integracja z mvn wygrywa. Gdyby nie to, pewnie bym sie przesiadl - zreszta jak w domu cos dlubie to czesto uzywam NB - ale ze robie to zadko, wiec ostatecznie nie moge sie zbytnio na temat NB wypowiadac.
Jak wyglada wsparcie NB dla innych jezykow? Wiem ze uzywac Scali i tam jest jakis plugin, ale ostatnio jak patrzylem to bylo dno. Jak np. Python - ostatnio moj ulubiony jezyk?
0
Mavena nie używałem, no chyba że trochę przy tworzeniu projektów z użyciem np Apache Wicket. W Comarchu boją się Mavena, bo mieli już spektakularną porażkę przy jego wdrażaniu :P Chyba cały czas jadą na CVS + swoje toole.
Jak trzeba ściągnąć projekt czysty z (D)VCSa to wystarczy go raz zaimportować i już jest OK.
Wtyczka dla Scali w NB jest strasznie kiepska, kompilacja projektu trwa minimum kilkanaście sekund. Chyba jakieś błędy (projektowe) są w tej wtyczce. Koleś co robi tą wtyczkę (tak, to tylko jeden koleś) jest pewnie zbyt zajęty, aby ją dopieszczać. Sprawdziłem za to ostatnio wtyczkę do Scali w Eclipse i tam już wydajność jest OK, kompilacja odbywa się praktycznie na bieżąco.
Python chyba został wyrzucony z listy oficjalnie wspieranych języków w NetBeansie i teraz jest community coś tam wersja.
0
Wibowit napisał(a)
Mavena nie używałem, no chyba że trochę przy tworzeniu projektów z użyciem np Apache Wicket. W Comarchu boją się Mavena, bo mieli już spektakularną porażkę przy jego wdrażaniu :P Chyba cały czas jadą na CVS + swoje toole.
No wlasnie, wiec nie masz tego problemu co ja (mimo to uwazam ze maven to jest state-of-the-art jesli chodzi o budowanie w javie; ale osobiscie wole gradle, ale to groovy).
Wlasne toole w Comarchu powiadasz - a znasz ich system kontroli wersji o nazwie bodajze PowerSource? Metodologia lock - ceckout - modigy - checkin - unlock tylko i wylacznie, bug na bugu itp itd. Tak, pracowalem tam kiedys i o ile sama prace wspominam dosc dobrze (wiele sie nauczylem), o tyle ich toole (PowerSource, jakies systemy kontroli czasu, jakis wlasny bugtracker) przemilcze z szacunku ;d
0
Nie wiem jaką ma nazwę ta ich metodologia. Mój dzień w Comarchu wyglądał tak: ściągnięcie kilkuset mega libków z folderu sieciowego po nocnej kompilacji, import kodu z CVS, potem testowanie programu (moje główne zajęcie) polegające na kompilacji modułu i wrzucenie go na serwer (za pomocą luźnych skrypcików) no i wgrywanie i poprawianie XMLi przez pół dnia, czekając aż w końcu przestaną się pojawiać błędy. XMLe były mapowane (tzn mapowanie nazw z jednej struktury do drugiej) na coś tam, potem to coś tam chyba było mapowane na strukturę bazy danych. Niestety tych mapowań nikt nie znał albo nie chciał mi udostępnić. Dokumentacja też używała jakichś chyba innych mapowań. Jakby tego jeszcze było mało, to nikt nie podawał informacji co zmieniał w strukturach XMLi. A więc rano po wgraniu XMLi na serwer dostawałem zwykle błąd polegający na błędnym formacie XMLa chociaż poprzedniego dnia wszystko było OK. No i musiałem poprawić strukturę moich testowych XMLi metodą chybił trafił albo prosić kogoś o nowe. W ogóle praca w Comarchu to szopka. Efektywność tragiczna, kod pisany chyba przez polaczka17 i brak jakiejkolwiek sensownej komunikacji. Dodam jeszcze że przy korzystaniu z CVS używałem programu WinCVS czy jakoś tak - tam zacommitowanie i otagowanie commita to była porażka. Nie pamietam już dokładnie ale chyba trzeba było tagować pliki po kolei oddzielnie :P Albo może i nie, ale trzeba było za to checkoutować przy tagowaniu czy jakoś tak - w sumie to było tak nielogiczne, że nie zapamiętałem jak to się odbywało. A i jeszcze: byłem w teamie z typem z Katowic, rozmawiałem przez telefon lub IM - można było godzinami pisać czy rozmawiać a i tak kupa z tego wyszła. Gdybyśmy się spotkali to praca przebiegałaby kilka razy szybciej.
Jak widać, importowanie Eclipsowego projektu do Eclipsa to przy tym pikuś :)
Na stażu wakacyjnym w Comarchu za to było OK: zrobiłem projekt w NetBeansie, korzystałem z NetBeansowej wtyczki do CVSa, grupka była trójosobowa i siedzieliśmy obok siebie. Efektywność wysoka, podział prac OK (ja rozdzielałem pracę), brak problemów z komunikacją czy synchronizacją roboty. No ale to jednak był dość mały projekt.
0
Ok, moja praca wygladala jednak inaczej ;d
Ale koniec offtopu moze.
0
Jakoś zawsze używałem netbeansa (na uczelni wymagali) i tak mi zostało. Teraz chcę się przerzucić na Eclipse, ponieważ netbeans nie dawal rady na moim kompie z mniej niż 1 GB ramu ;) a Eclipse działa świetnie i uruchamia się. Muszę tylko się go jeszcze nauczyć ehhe :P
0
No to może ktoś się wypowie coś o IntelliJ IDEA. Wydaje się być fajnym IDE. Jest płatne, podobnie jak VS. W Polsce chyba jest nawet dość popularne. Tak się zastanawiam czy się nie przesiadać, w końcu NetBeans się degraduje pod rządami Oracla, a Eclipse jest w ogóle przekombinowane i nie podchodzi mi, a IDEA majątku nie kosztuje. Gdybym poszedł do normalnej roboty, to większa efektywność byłaby bardzo OK. Jak wygląda sprawa z licencjami? Jeżeli np firma nie kupuje licencji na IDEĘ to mam kupić tą droższą korporacyjną czy osobistą tańszą?
0
Idea jest nienajgorsza, można otworzyć plik z pliku ipr bodajże, co jest bardzo, ale to bardzo na plus.
Więcej się nie wypowiem, bo jestem uprzedzona do Javy i VS jest dla mnie jedynym słusznym IDE ;)
0
Nie ma sie co uprzedzac, tylko korzystac z tego co jest ;d W VS jest niezly, ale nie jedyny sluszny i nie o tym temat ;d
0
Oba ssą z powodu zajętości RAMu.
NetBeans wydaje się fajniejszy (testowane z PHP), ale 700MB RAMu zanim otworzyłem pierwszy plik przyprawia o palpitacje serca.
Eclipse zżerał koło 400MB na start.
Aptana (bazująca na Eclipse) coś koło 180MB - i tak masakra w porównaniu z moim edytorkiem (2.8MB), ale najlepiej z całej trójki.
Brakuje mi VisualStudio Express PHP :)
0
mućka napisał(a)
Pytanie do uzytkownikow VS - jakich systemow kontroli wersji uzywacie? Jakies zintegrowane czy cokolwiek co sie w tej chwili uzywa (hg, bzr, git, svn, ...)? Sa jakies wtyczki do tego, czy TortoiseHG i jazda? Wersjonujecie pliki projektowe / solucji?
Nie, a po co? Wystarcza zip i FTP. ;P
W pracy używam TFS (produkt MS) - ładnie się integruje z VS, działa dość dobrze, kosztuje miliard miliardów. (To zresztą nie tylko kontrola wersji ale i issue tracker, tyle że poza programistami nikt nie potrafi tych funkcji używać.)
W poprzedniej pracy był Visual Source Safe - też od MS, technologia sprzed wielu lat, oparte na plikach - w zasadzie normą jest, że coś się nie uda, albo jakiś kod straci. Nikt normalny tego chyba już nie używa. Ale nienormalnych przecież nie brakuje. I z tym też trzeba było pracować na zasadzie lock - modify - unlock, tylko po tym trzeba jeszcze repair, ale to już ręcznie. :)
Do SVN jest oczywiście Tortoise, ale jest też ładnie integrująca się z VS wtyczka: AnkhSVN.
Jeśli chodzi o git to niestety nie jest tak ładnie. Wtyczka do VS w zasadzie uruchamia zewnętrzną aplikację GitExtensions z odpowiednimi parametrami, więc trzeba w zasadzie jeszcze tam kliknąć kilka przycisków lub coś w tym stylu.
Wibowit napisał(a)
Nie wytłumaczyliście dlaczego wg was solucje z VS są lepsze od rozwiązań z Eclipse czy NetBeans
Pewno dlatego, że nikt tu takiej tezy nie stawiał. :)
Ja się czepiam tylko do braku jednoznacznej opcji Open w Eclipse.
nie wytłumaczyliście mi również czemu importujecie projekt Eclipsowy do Eclipsa zamiast po prostu otworzyć workspace.
Hmm... No tak! Skoro workspace w przybliżeniu to solution, więc (ana)logicznym byłoby je otwierać w całości. Tylko, jakoś opcji Open workspace też brak. (Tak, wiem, znalazłem już Switch. Tylko czemu znowu jest wszystko inaczej. ;P). Sprawdzę przy okazji czy to zadziała.
mućka napisał(a)
Zgadzam sie w 100%. Tym smieszniej, ze eclipse robi jakies swoje ukryte pliki (chocby .project) wiec moglby umiec otworzyc projekt na dwuklik - a nie umie.
Może twórcy nie potrafią obsłużyć argumentów wywołania programu? ;)
To jest nieprawda. Eclipse wymaga zawsze workspace, ale moze on byc pusty, i skladowac jedynie metadane / ustawienia (jak np servery aplikacji, jakies ustawienia wtyczek itp) w podkatalogu .metadata. Wszystko inne podczas importowania mozna zostawic w innych, dowolnych miejscach. Tutaj nie masz kompletnie racji. Mozliwe ze to ze nie udalo Ci sie importowac bez kopiowania wynika z ogolnie znanej stabilnosci Eclipse? Mi sie jednak udaje.
Przeprowadziłem dalsze śledztwo i tak - zwykły Java Project faktycznie można zaimportować z dowolnej lokalizacji i działa. Tylko, że ja potrzebuję to samo zrobić dla J2ME Midlet Suite, a w tym przypadku jeśli nie skopiuję plików do workspace, to po prostu się nie skompiluje twierdząc, że nie może znaleźć pakietów z ME.
mućla napisał(a)
Stad tez moje pytanie do VS-userow - czy wersjonuja te pliki VS? Jako ze VS jest jeden, i to tylko pod Windowsa, jestem sklonny stwierdzic ze bym sie posunal do takiego rozwiazania, ale mozliwe ze to calkowicie zle podejscie?
W zasadzie w VS są trzy typy plików:
- csproj (vbproj, i analogicznie dla innych języków), w nich jest konfiguracja projektu, wersja frameworka, podstawowy namespace, konfiguracja buildu, referencje, no i lista plików projektu;
- sln, w nim jest lista projektów i konfiguracja dostępnych opcji kompilacji (debug/release, x86/x64);
- suo, w nim jest info o ostatnio otwartych plikach, wstawionych breakpointach, zawartości niektórych okienek używanych w trakcie debugowania, itp.
Dwa pierwsze są tekstowe, czytelne dla człowieka, drugi jest binarny i domyślnie ukryty. Dwa pierwsze się wersjonuje, żeby wszyscy członkowie zespołu mieli tą samą konfigurację projektów. Ostatniego nie, bo to byłby już absurd. :)
0
somekind napisał(a)
- sln, w nim jest lista projektów i konfiguracja dostępnych opcji kompilacji (debug/release, x86/x64)
Ustawia sie architekture procka na jaka sie buduje? Myslalem ze jedna z idei VM (a CLR jest VM jakby nie bylo) jest abstrakcja takich rzeczy?
0
True. Myslac VS mam przed oczyma C# i .NET, a przeciez to nieprawda.
0
Domyślnie jest zresztą "Any CPU". Ale projekt skompilowany na tę platformę, uruchomiony na procesorze x64 i korzystający z 32bitowych natywnych bibliotek nie zadziała, dlatego musi być możliwość wymuszenia na nim startu jako proces 32bitowy.
0
Czyli jednak masz na myśli CLR? W Javie mogę sobie napisać program korzystający z natywnych bibliotek i bez rekompilacji odpalić na Win/ Lin/ MacOS/ Sol/ itd 32/ 64 bit.
0
Mógłbyś pokazać przykład takiego programu wraz z natywną biblioteką na te wszystkie systemy i platformy?
Nie jestem ekspertem od CLR, kompilacji ani dlaczego dokładnie istnieje to rozróżnienie. Wiem tylko, że muszę zmienić ustawienia jeśli trafię na taki wyjątek: http://msdn.microsoft.com/en-us/library/system.badimageformatexception.aspx