mboost-dp1
Java/Eclipse: Versionsstrying af WAR files
Findes der en måde at tilføje sin WAR fil som indeholder client-filer som HTML, CSS og Javascript, til SVN uden at man også får alle ens compiled .class filer med?
Pt. synes Eclipse det er hylende morsomt at tilføje alle .class filerne, uden at give mulighed for IKKE at tilføje dem til SVN.
Og at ignorer hele war packagen, og manuelt tilføje hver eneste client-side fil der skal med er idioti på et niveau det er svært at tro på.
Pt. synes Eclipse det er hylende morsomt at tilføje alle .class filerne, uden at give mulighed for IKKE at tilføje dem til SVN.
Og at ignorer hele war packagen, og manuelt tilføje hver eneste client-side fil der skal med er idioti på et niveau det er svært at tro på.
#1
Nu bruger jeg CVS i.s.f. SVN. Og sandsynligvis er min opsætning anderledes end din på mange andre måder.
Men jeg vil alligevel tro at:
- du skal have dit statiske indhold som selvstændige filer i Eclipse (på samme måde som dynamisk indhold - eventuelt bare i andet subdirectory)
- du manuelt tilføjer de filer som skal ind i source control til source control (formentligt markerer du dem alle og vælger team commit i en enkelt operation)
- du genererer en war fil med statisk indhold, dynamisk indhold som først skal compiles ved deployment (default for JSP), diverse binær kode (class og jar filer)
- hvis war filen skal releases ud af huset, så tilføjer du også den til source control (for at have en eksakt kopi af hvad brugerne har)
Nu bruger jeg CVS i.s.f. SVN. Og sandsynligvis er min opsætning anderledes end din på mange andre måder.
Men jeg vil alligevel tro at:
- du skal have dit statiske indhold som selvstændige filer i Eclipse (på samme måde som dynamisk indhold - eventuelt bare i andet subdirectory)
- du manuelt tilføjer de filer som skal ind i source control til source control (formentligt markerer du dem alle og vælger team commit i en enkelt operation)
- du genererer en war fil med statisk indhold, dynamisk indhold som først skal compiles ved deployment (default for JSP), diverse binær kode (class og jar filer)
- hvis war filen skal releases ud af huset, så tilføjer du også den til source control (for at have en eksakt kopi af hvad brugerne har)
#1
Ja, du laver en Ant build hvor du selv vælger hvilke filer du vil have inkluderet i WAR filen. Ganske som normalt.
Tudefjæs! Tudefjæs! Tudefjæs!
Du kan alligevel ikke slippe din fascination af Java og Eclipse alligevel hva... Det er bare et spørgsmål om tid Hr. Jørgensen. Come to the darkside. Join us!
Findes der en måde at tilføje sin WAR fil som indeholder client-filer som HTML, CSS og Javascript, til SVN uden at man også får alle ens compiled .class filer med?
Ja, du laver en Ant build hvor du selv vælger hvilke filer du vil have inkluderet i WAR filen. Ganske som normalt.
Pt. synes Eclipse det er hylende morsomt at tilføje alle .class filerne, uden at give mulighed for IKKE at tilføje dem til SVN.
Tudefjæs! Tudefjæs! Tudefjæs!
Og at ignorer hele war packagen, og manuelt tilføje hver eneste client-side fil der skal med er idioti på et niveau det er svært at tro på.
Du kan alligevel ikke slippe din fascination af Java og Eclipse alligevel hva... Det er bare et spørgsmål om tid Hr. Jørgensen. Come to the darkside. Join us!
Du kan sagtens bruge ant til at køre i development mode (hvad de i <2.0 kalde for hosted mode) jvnf. dette link:
http://code.google.com/webtoolkit/gettingstarted.h...
http://code.google.com/webtoolkit/gettingstarted.h...
Jeg hader virkelig at Eclipse sletter min kode konstant.
Jeg har forsøgt at lave følgende struktur:
demo/src
demo/www
demo/war
Hvor at demo/src skal deployes til demo/war/WEB-INF/classes, og demo/www skal deployes til demo/war/
Men Eclipse synes det er meget sjovere at slette alt indholdet i war/WEB-INF hvis jeg forsøger på det. Uden at bede om bekræftelser, eller overhovedet at fortælle mig det.
Jeg har forsøgt at lave følgende struktur:
demo/src
demo/www
demo/war
Hvor at demo/src skal deployes til demo/war/WEB-INF/classes, og demo/www skal deployes til demo/war/
Men Eclipse synes det er meget sjovere at slette alt indholdet i war/WEB-INF hvis jeg forsøger på det. Uden at bede om bekræftelser, eller overhovedet at fortælle mig det.
Windcape (8) skrev:Jeg hader virkelig at Eclipse sletter min kode konstant.
Nej, det er ikke Eclipse der sletter din kode konstant, det er GWT plugin'et der er beregnet til at compilere sources on-the-fly til et forud defineret target.
Windcape (8) skrev:Uden at bede om bekræftelser, eller overhovedet at fortælle mig det.
Desværre, Eclipse er ikke UAC :)
Windcape (10) skrev:Nej, Eclipse sletter dele af koden ved forkert opsætning af Output Folders i Java Build Path.
Ja, ved forkert opsætning! Det kan du ikke give Eclipse skylden for.
Windcape (10) skrev:Det er et problem baseret på Eclipse's ide om at køre på filsystemet, i stedet for at have projektfiler med filhåndtering deri.
Sludder! Opsætning af, og konceptet med workspaces er lige netop for at kunne separere kode, samt konfiguration af samme. At du så ikke har gjort dette, kan igen ikke være Eclipses skyld.
Windcape (10) skrev:Hack oven på hack oven på hack *sigh*
Whine oven på whine oven på whine *suk* :)
#11
Hvordan kan det nogen sinde virke logisk at OUTPUT folders af compilation skulle slette kode der er en del af ens PROJEKT.
F.eks. Visual Studio bliver filerne bare fjernet fra project-view hvis der sker noget. De ligger stadigvæk på filsystemet, hvis du vælger ikke at inkludere dem.
Eclipse synes det er sjovere at slette dem PERMANENT. At flytte dem til papirkurven ville være utrolig behagelig i stedet.
Hvordan kan det nogen sinde virke logisk at OUTPUT folders af compilation skulle slette kode der er en del af ens PROJEKT.
F.eks. Visual Studio bliver filerne bare fjernet fra project-view hvis der sker noget. De ligger stadigvæk på filsystemet, hvis du vælger ikke at inkludere dem.
Eclipse synes det er sjovere at slette dem PERMANENT. At flytte dem til papirkurven ville være utrolig behagelig i stedet.
#12
Hvis Eclipse og Java er for svært for dig, hvorfor holder du dig så ikke bare til C# og Visual Studio så du bliver holdt i hånden?
Gør en ende på dine frygteligt pinsler.
Eclipse er lavet til professionelle programmører der ved hvad de laver, så jeg forstår godt hvorfor du ikke kan finde ud af det.
Hvis Eclipse og Java er for svært for dig, hvorfor holder du dig så ikke bare til C# og Visual Studio så du bliver holdt i hånden?
Gør en ende på dine frygteligt pinsler.
Eclipse er lavet til professionelle programmører der ved hvad de laver, så jeg forstår godt hvorfor du ikke kan finde ud af det.
Windcape (12) skrev:Hvordan kan det nogen sinde virke logisk at OUTPUT folders af compilation skulle slette kode der er en del af ens PROJEKT.
Ja, det ved jeg godt nok heller ikke, men eftersom du har konfigureret projektet således, så skal Eclipse da ikke gå ind og modarbejde dig? (jvnf #8)
Windcape (12) skrev:Eclipse synes det er sjovere at slette dem PERMANENT. At flytte dem til papirkurven ville være utrolig behagelig i stedet.
Fordi papirkurven, clippy og søgehunden fra Windows XP burde dø en grusom død. Enten sletter man ting, ellers gør man ikke. Du kan jo også bare bruge din "Local history" funktionalitet i Eclipse, til at se ældre revisioner.
Jeg tror også bare at det ville være mere fornuftigt at du holdte dig i Visual Studio, i nogle teknologier som du har kompetence indenfor, med mindre du lærer at affinde dig med at altid ikke virker som Visual Studio.
Hvis du ikke synes det er en god løsning, og du død og pine skal udvikle i Eclipse, så kan du jo kaste dig over at skrive nogle Plugins som udfører lige netop den funktionalitet som du efterspørger.
#14
Man er da om noget et fjols hvis man affinder sig med kodetab og dårligere funktionalitet.
Jeg forstår ikke attituden med at man skal affinde sig med problemer, bare fordi det er en anden teknologi.
Jeg som udvikler kan ikke bruge en teknologi til noget som helst, hvis det ikke giver andet end problemer når det kommer til konfiguration af de tilhørende værktøjer.
Og det ER et problem med Eclipse at den bygger alting på filsystemet, og ikke har output folders i stil med VS.
Man er da om noget et fjols hvis man affinder sig med kodetab og dårligere funktionalitet.
Jeg forstår ikke attituden med at man skal affinde sig med problemer, bare fordi det er en anden teknologi.
Jeg som udvikler kan ikke bruge en teknologi til noget som helst, hvis det ikke giver andet end problemer når det kommer til konfiguration af de tilhørende værktøjer.
Og det ER et problem med Eclipse at den bygger alting på filsystemet, og ikke har output folders i stil med VS.
Og så tror jeg min løsning på problemet bliver at ignorer dum brug af revisionskontrol, og bare lade den uploade alting, og håbe det ikke skaber inkonsistens.
Det er simpelthen ikke værd at spilde mere tid på konfiguration af Eclipse, med de katestrofale følger det giver.
Det er simpelthen ikke værd at spilde mere tid på konfiguration af Eclipse, med de katestrofale følger det giver.
Jeg forstår simpelthen ikke hvordan du kan brokke dig så meget.....
Eclipse har da sine små særheder, men dem lærer man hurtigt at kompensere for- og så er det et helt utroligt fleksibelt og effektivt miljø at arbejde i.
Jeg tror vi alle sammen har haft det lidt ligesom dig, bortset fra at når der er noget vi ikke lige finder intuitivt klør vi os selv i nakken, og tænker, nå så må jeg nok gøre det på anden måde.
Din strategi er så at whine whine whine, og forbande programmet istedet for at overveje at din tilgang til det måske er lidt forkert.
Jeg arbejder inden for j2ee og har aldrigt hørt om nogen der er utilfredse med Eclipse. Eller jo, sådan 1 minuts brok hist og her- men der er altså en grund til at det er nærmest en industri standard.
Og jeg er på ingen måde biased overfor eclipse, jeg er også glad for visual studio, hvilket jeg foretrækker til c++ udvikling.
Og så tag da og sæt en subversion server op og smæk skildpadden på hvis det er så vigtigt.....
Eclipse har da sine små særheder, men dem lærer man hurtigt at kompensere for- og så er det et helt utroligt fleksibelt og effektivt miljø at arbejde i.
Jeg tror vi alle sammen har haft det lidt ligesom dig, bortset fra at når der er noget vi ikke lige finder intuitivt klør vi os selv i nakken, og tænker, nå så må jeg nok gøre det på anden måde.
Din strategi er så at whine whine whine, og forbande programmet istedet for at overveje at din tilgang til det måske er lidt forkert.
Jeg arbejder inden for j2ee og har aldrigt hørt om nogen der er utilfredse med Eclipse. Eller jo, sådan 1 minuts brok hist og her- men der er altså en grund til at det er nærmest en industri standard.
Og jeg er på ingen måde biased overfor eclipse, jeg er også glad for visual studio, hvilket jeg foretrækker til c++ udvikling.
Og så tag da og sæt en subversion server op og smæk skildpadden på hvis det er så vigtigt.....
Windcape (15) skrev:Man er da om noget et fjols hvis man affinder sig med kodetab og dårligere funktionalitet.
Nej - forkert! Man er et fjols når man konfigurerer sit IDE til at bidrage til kodetab og dårligere funktionalitet.
Hvorfor tager du nu ikke bare og konfigurerer dit subversion setup korrekt, global-ignores sektionen er temmelig kraftfuld. Den kan du finde i filen:
C:\Users\<username>\AppData\Roaming\Subversion\config
min global-ignores står forresten til "bin classes", den ser ud til at klare jobbet for mig i mit GWT / Java / PHP udviklingssetup (som kører i eclipse).
#17
Jeg er jo nok bare mere kritisk over for de produkter jeg bruger, end de fleste andre mennesker. Og jeg har tid til at være kritisk og undersøge hvordan man kan forbedre brugen af produktet, da jeg ikke har en chef hængende over nakken som brokker sig over man undersøger konfiguration mulighederne.
Jeg er jo nok bare mere kritisk over for de produkter jeg bruger, end de fleste andre mennesker. Og jeg har tid til at være kritisk og undersøge hvordan man kan forbedre brugen af produktet, da jeg ikke har en chef hængende over nakken som brokker sig over man undersøger konfiguration mulighederne.
#19
Fint, så kan du indstille selvsamme funktionalitet under:
Window > Preferences
Ekspander træet til følgende sti:
Team > Ignored Resources
#20
Vi kan godt være enige om at du er kritisk over for de produkter du bruger, men du er godt nok også MEGET biased overfor dine oplevelser med VS.
Jeg synes ærlig talt ikke at du:
a) bruger tilstrækkeligt med tid til at konfigurere / undersøge mulighederne for konfiguration af produkterne.
b) kritiserer hæmningsløst når du ikke kan klikke på en knap, og produktet gør ALTING for dig.
Du kommer nok til at have det noget vanskeligt når du kommer ud i erhvervslivet - for det er ikke point'n'click - desværre.
Fint, så kan du indstille selvsamme funktionalitet under:
Window > Preferences
Ekspander træet til følgende sti:
Team > Ignored Resources
#20
Vi kan godt være enige om at du er kritisk over for de produkter du bruger, men du er godt nok også MEGET biased overfor dine oplevelser med VS.
Jeg synes ærlig talt ikke at du:
a) bruger tilstrækkeligt med tid til at konfigurere / undersøge mulighederne for konfiguration af produkterne.
b) kritiserer hæmningsløst når du ikke kan klikke på en knap, og produktet gør ALTING for dig.
Du kommer nok til at have det noget vanskeligt når du kommer ud i erhvervslivet - for det er ikke point'n'click - desværre.
Vi er alle kritiske, og hvis der eksisterede noget der var bedre end eclipse(Myeclipse) til j2ee udvikling skiftede jeg da gerne- men det gør der ikke, og eclipse er faktisk helt utroligt god- især pga. dets plugin system.
Men ja- erhverslivet bliver virkeligt hårdt for dig- hvis du ikke engang kan finde ud af at google basale ting om hvordan du konfigurerer en GUI- men skal spørge hver gang på et forum. + Hvis du ikke holder op med at whine sådan bliver du da en irreterende kollega?
Men ja- erhverslivet bliver virkeligt hårdt for dig- hvis du ikke engang kan finde ud af at google basale ting om hvordan du konfigurerer en GUI- men skal spørge hver gang på et forum. + Hvis du ikke holder op med at whine sådan bliver du da en irreterende kollega?
Man kan jo bevist undgå at arbejde med Java, og undgå alle problemerne der.Corholio (21) skrev:Du kommer nok til at have det noget vanskeligt når du kommer ud i erhvervslivet - for det er ikke point'n'click - desværre.
F.eks. tillader Eclipse ikke engang svn:ignore på et projekt der IKKE er committet endnu. Hurra for elendighed!
(Samt det slet ikke kan lade sig gøre efter commit... underligt og elendigt).
om jeg fatter hvordan du kan være så vild med c# og hade java så meget.....
personligt tænker jeg slet ikke over hvilket af de sprog jeg koder i, og ja jeg udnytter dem fuldt ud.
Din java angst kommer du sikkert over når du har siddet og lavet c# i en 3 år, og det begynder at kede dig og du vil prøve noget nyt.
personligt tænker jeg slet ikke over hvilket af de sprog jeg koder i, og ja jeg udnytter dem fuldt ud.
Din java angst kommer du sikkert over når du har siddet og lavet c# i en 3 år, og det begynder at kede dig og du vil prøve noget nyt.
Og hvis i tror at .NET er point'n'click, så tro om.Corholio (21) skrev:or det er ikke point'n'click
Man skal bare ikke spilde så meget tid på konfiguration i Microsoft's software. De kan godt lide at gøre det nemt for udviklerne.
Og jeg er stadigvæk skuffet over at skulle se på build-output i min Package Explorer.
jeg er ganske tilfreds med enhver standard subversion/cvs, continium/cruise control, maven/ant, eclipse/myeclipse, jboss/websphere/jonas stack..... og der kan ms altså ikke diske op med noget der kommer tæt på....
Windcape (26) skrev:#24
Alle andre end Java er da mange :-)
Specielt med .NET 4 CLR.
Ok, I stand corrected. Men du vil stadigvæk helst opholde dig i VisualStudio... fint med mig, jeg vil hellere opholde mig i et miljø der interfacer med IDE-agnostiske teknologier, så som ant og Maven.
Windcape (26) skrev:#25
Jeg har arbejdet med Java i over 5 år. Der er bare seriøse problemer med udviklingsværktøjerne til Java teknologierne.
Tjah, vi kan tale om at IDE'erne måske ikke er totalt bling-bling. Jeg vil hårdnakket påstå at udviklingsværktøjerne til java er stærk overlegne og mere modne end dem på .net / CLR-siden.
#28
Der er jo ikke noget som hedder standard i Eclipse. Du skal vælge mellem en masse plugins. Jeg er dybt skuffet over kvaliteten af de 2 SVN plugins til Eclipse, og specielt hvor fatsvage de er mht. svn:ignore.
Men i lader jo til at være ligeglad med problemerne, og laver bare et commandline/filsystem fix, hvis Eclipse bugger. Og så henter i en kop kaffe mens Eclipse genstarter.
Derudover så er der jo Microsoft's Team Server som gør hvad du efterspørger. Ellers kan du jo godt vælge en open-source stack, hvor alt hvad du har påpeget findes i en version til .NET
Der er jo ikke noget som hedder standard i Eclipse. Du skal vælge mellem en masse plugins. Jeg er dybt skuffet over kvaliteten af de 2 SVN plugins til Eclipse, og specielt hvor fatsvage de er mht. svn:ignore.
Men i lader jo til at være ligeglad med problemerne, og laver bare et commandline/filsystem fix, hvis Eclipse bugger. Og så henter i en kop kaffe mens Eclipse genstarter.
Derudover så er der jo Microsoft's Team Server som gør hvad du efterspørger. Ellers kan du jo godt vælge en open-source stack, hvor alt hvad du har påpeget findes i en version til .NET
MSBuild ? Du har jo også mulighed for automatiserede unit-tests og andre build-commands med Team Server.Corholio (29) skrev:jeg vil hellere opholde mig i et miljø der interfacer med IDE-agnostiske teknologier, så som ant og Maven
Hvis"modent" betyder bloatet, overdrevent tungt, og består af flere års hacks på hacks, så ja.Corholio (29) skrev:Jeg vil hårdnakket påstå at udviklingsværktøjerne til java er stærk overlegne og mere modne end dem på .net / CLR-siden.
Fordelen ved .NET miljøet er at man typisk kigger på hvad vi rent faktisk har brug for. Du finder ikke en 1000 pixel høj kontext-menu i Visual Studio.
Eclipse har 10000 features jeg aldrig kommer til at bruge. De laver ikke andet end gør programmet tungt og træls at arbejde med.
Hvordan er det modent?
Eclipse burde fokusere på grundlæggende ting, og have ting som SVN integration som et *standard* plugin, i stedet for alt det andet.
Det er jo vel hele grunden til at folk benytter MyEclipse, IBM Rational, etc. Fordi at standard-installationen er elendig, og kræver mere konfiguration end en standard-udvikler nogen sinde vil kende til.
Det burde være ret åbenlyst hvorfor Eclipse er så super fustrende for nye brugere af det. Specielt hvis de brugere har erfaringer med andre produkter i forvejen.
#30
Det er også derfor jeg foretrækker myeclipse, den koster vist 30$ ( VS koster jo også) der er en standard....alt er sat op til j2ee udvikling og alle plugins er præinstalleret....et skønt miljø :)
eclipse er crashet 2-3 gange for mig på 2 år- så jeg plejer at hente min kaffe mens mit c++ compiler( i visual studio)- jeg er personligt heller ikke glad for eclipses svn integration- den kan drille, de andre på mit team er dog tilfredse, så min første mistanke er at jeg bare er en skovl til at bruge det. Derfor bruger jeg skildpadden....(point and click også)
Det er også derfor jeg foretrækker myeclipse, den koster vist 30$ ( VS koster jo også) der er en standard....alt er sat op til j2ee udvikling og alle plugins er præinstalleret....et skønt miljø :)
eclipse er crashet 2-3 gange for mig på 2 år- så jeg plejer at hente min kaffe mens mit c++ compiler( i visual studio)- jeg er personligt heller ikke glad for eclipses svn integration- den kan drille, de andre på mit team er dog tilfredse, så min første mistanke er at jeg bare er en skovl til at bruge det. Derfor bruger jeg skildpadden....(point and click også)
winescape skrev:Fordelen ved .NET miljøet er at man typisk kigger på hvad vi rent faktisk har brug for. Du finder ikke en 1000 pixel høj kontext-menu i Visual Studio.
Ja- det er rart, og det er også noget man mærker i selve libariet, i forhold til javas libary- men jesus fucking christ, det er da ikke noget der går mig på, eller kan få mig til at vælge det ene eller det andet.
Det er bare SMÅTING- sq da ikke noget at whine over på et forum, eller fravælge teknologier pga.
Til gengæld har java andre fordele.
Jeg mistænker lidt at alt du ikke med det samme kan finde ud af bliver til dårlige ting i din verden.
Fanatisme indenfor teknologier er ikke godt.
Hvad regner du med at komme til at lave når du er færdiguddannet?
Jeg mistænker lidt at alt du ikke med det samme kan finde ud af bliver til dårlige ting i din verden.
Fanatisme indenfor teknologier er ikke godt.
Hvad regner du med at komme til at lave når du er færdiguddannet?
Men at vælge det rigtige værktøj er godt ikke?moveax1ret (35) skrev:Fanatisme indenfor teknologier er ikke godt.
Det er for nemt at kalde folk fanatikere ligeså snart de begynder at sammenligne teknologier. Det sker sjovt nok kun når man sammenligner <X> teknologi med <Microsoft Teknologi>. Så på det punkt er jeg lidt kold nu om dage.
Jeg ser deployment fordelen ved JEE som marginale i forhold til udviklingsfordelene under .NETmoveax1ret (35) skrev:Til gengæld har java andre fordele
Alt andet end Java EE.moveax1ret (35) skrev:Hvad regner du med at komme til at lave når du er færdiguddannet?
Windcape (31) skrev:Hvis"modent" betyder bloatet, overdrevent tungt, og består af flere års hacks på hacks, så ja.
Så må du godt nok frygte VS om nogle år, når der kommer til at "lide" af de samme problemer.
Windcape (31) skrev:Fordelen ved .NET miljøet er at man typisk kigger på hvad vi rent faktisk har brug for. Du finder ikke en 1000 pixel høj kontext-menu i Visual Studio.
Ja, det er samme funktionalitet og fordel som Eclipse har med deres opdeling IDE'et i perspectives, mv. Du kan forresten ikke klandre Eclipse for at du har integreret så mange plugins, at context menuen bliver så høj.
Windcape (31) skrev:Eclipse har 10000 features jeg aldrig kommer til at bruge.
Nej, men nu er du tilfældigvis heller ikke den eneste person der benytter sig af Eclipse, man skal tilgodese hele brugerskaren af sit produkt.
Windcape (31) skrev:De laver ikke andet end gør programmet tungt og træls at arbejde med.
Jeps, jeg er sikker på det lige netop er den formulering de bruger i deres ansættelseskontrakter for udviklerne.
Windcape (31) skrev:Hvordan er det modent?
Modent, som i - de har flere år på bagen, har released en hel del versioner.
Windcape (31) skrev:Eclipse burde fokusere på grundlæggende ting, og have ting som SVN integration som et *standard* plugin, i stedet for alt det andet.
Hvordan ser du lige at SVN integration er en defacto standard, du kan da ikke sige at alle udviklere bruger Subversion til versionsstyring. Den indbyggede CVS-understøttelse ligger til grund i at de rent faktisk bruger CVS til versionstyring af deres sources, og de vil gerne "eat-their-own-dogfood".
Winecape skrev:Jeg ser deployment fordelen ved JEE som marginale i forhold til udviklingsfordelene under .NET
Der er også ting som at det kan køre på mange operativsystemer, dets lækre application servere, hibernate, eclipse etc.
Windcape (34) skrev:Og IDE integrationen betyder meget, specielt under en indlærings process.
Sjovt, der ville jeg jo mene at forståelse af teknologien er alfa-omega under en indlæringsprocess.
IDE-integration kan være mere eller mindre ligegyldigt, da du sjældent kan diktere hvilket miljø du vil benytte dig af (i erhvervslivet).
Visual Studio 2010 var begyndt at lide af det, så Microsoft satte 3-4 uger ekstra af til udviklingen, fordi at brugerne klagede (i beta testen).Corholio (37) skrev:Så må du godt nok frygte VS om nogle år, når der kommer til at "lide" af de samme problemer.
Vi snakkede med Mads Torgensen omkring det til sidste års JAOO, hvor han sagde at det ville blive hurtigere i beta 2 (det blev det også, men ikke nok.
Eclipse kunne trænge til mere fokus på performance.
Ikke i teknologier som GWT eller Android!Corholio (39) skrev:Sjovt, der ville jeg jo mene at forståelse af teknologien er alfa-omega under en indlæringsprocess.
IDE-integration kan være mere eller mindre ligegyldigt, da du sjældent kan diktere hvilket miljø du vil benytte dig af (i erhvervslivet).
(Eller WPF, hvis man skulle tage et .NET eksempel)
Windcape (40) skrev:Ikke i teknologier som GWT eller Android!
Hvis du mener at GWT eller Android dikteres af hvilket IDE de udvikles under, så tager du altså grotesk fejl.
Disse teknologier er IDE-agnostiske, dog leverer Google en del convenience tools, såfremt du benytter dig af Eclipse som udviklingsplatform.
#41
At lære et API i et kendt sprog er aldrig et problem. Problemet er at lære de værktøjer som man bruger til at udvikle med APIet i praktis.
Du kan lære XAML på 2 uger, men du skal bruge et par månder for at arbejde effiktivt i Expression Blend.
Udviklingsværkøjer er vigtigere end APIet i sådanne teknologier. Det samme gælder for GWT.
At lære et API i et kendt sprog er aldrig et problem. Problemet er at lære de værktøjer som man bruger til at udvikle med APIet i praktis.
Du kan lære XAML på 2 uger, men du skal bruge et par månder for at arbejde effiktivt i Expression Blend.
Udviklingsværkøjer er vigtigere end APIet i sådanne teknologier. Det samme gælder for GWT.
moveax1ret (42) skrev:det eneste der er for slow i eclipse er opstart, derfor lukker jeg den aldrigt- problem solved :)
Bliver det ikke lidt dyrt i strømforbrug?
Jeg kan nikke genkendende til at Eclipse ikke starter op i løbet af sekunder, men desideret langsom... njah, 1 minuts tid, så kører det?
Jeg ser det ikke som en generel hindring, da jeg kun starter miljøet op en gang om dagen, men hvis man sidder akut og mangler sit IDE starter op, kan det være lidt træls.
#45
det ved jeg ikke om det bliver, det er en arbejdspc, som jeg remoter til over vpn hvis jeg arbejder hjemmefra.
det ved jeg ikke om det bliver, det er en arbejdspc, som jeg remoter til over vpn hvis jeg arbejder hjemmefra.
Windcape (43) skrev:Udviklingsværkøjer er vigtigere end APIet i sådanne teknologier. Det samme gælder for GWT.
Nej, det er det så ikke. GWT er Java og XML, Java og XML kan skrives i Notepad (hvis du masochist), eller enhver anden lightweigt editor.
Du bruger derefter ant, eller anden byggemekanisme til at processere din source.
Windcape (46) skrev:Til sammenligning er Eclipse omkring 15-20 sekunder langsommere til at starte op end Windows 7 på min maskine ;-)
(Windows starter på omkring 28 sekunder).
Wow... imponerende! Føler du at du står og mangler de 15-20 sekunder hver dag, giv mig et faktisk eksempel?
Ja, det var jo pointen?Corholio (48) skrev:Nej, det er det så ikke. GWT er Java og XML, Java og XML kan skrives i Notepad (hvis du masochist), eller enhver anden lightweigt editor.
Du bruger derefter ant, eller anden byggemekanisme til at processere din source.
GWT og Android ville være håbløse at udvikle i uden et IDE.
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund