mboost-dp1
Java/Eclipse: Versionsstrying af WAR files
ja- det er lidt skidt....nu står du i en situation hvor at din fanatisme afholder dig fra at bruge det bedste værktøj. Du ved det er det bedste værktøj- hvorfor det er det kan så være ligemeget. Bare brug det, og stop med at whine, du skal nok lære at blive god til det engang.
Windcape (52) skrev:#51
Jeg whiner ikke, jeg påpeger kritik punkter, som jeg så håber folk kan sige "ah, det kan du løse sådan her".
Men typisk er svaret "vend dig til det!"
Dit spørgsmål gik på hvordan du skulle ignorere resourcer i subversion, det gav jeg svar på i post #3, #18 og igen i #19 (uden at ændre i et konfigurationsfil)
Så du er lige netop kun ude på at påpege kritikpunkter, og vil ikke lytte til de løsningsforslag vi kommer med - ergo, du whiner!
Forresten, for dem der ikke er klar over alternativerne, kan jeg henvise til den anden "eclipse"-tråd vi har kørende:
http://newz.dk/forum/programmering/type-ahead-auto...
http://newz.dk/forum/programmering/type-ahead-auto...
Windcape (15) skrev:Man er da om noget et fjols hvis man affinder sig med kodetab og dårligere funktionalitet.
Det er dig der oplever de problemer, ikke os.
Windcape (20) skrev:Jeg er jo nok bare mere kritisk over for de produkter jeg bruger, end de fleste andre mennesker.
Nej, du whiner mere. Det er noget helt andet. Og jeg har kun set dig gøre det om non-Microsoft produkter.
Windcape (23) skrev:Man kan jo bevist undgå at arbejde med Java, og undgå alle problemerne der.
Ja, vil du ikke nok, please please please?
Jeg kan ikke lide C# og .net, så det arbejder jeg ikke med. Problem løst.
Windcape (27) skrev:Og jeg er stadigvæk skuffet over at skulle se på build-output i min Package Explorer.
Lær at leve med det. ;-)
Alternativt kunne du sætte dig ind i problemet og løse det, ligesom os andre. Jeg ser aldrig på build-output medmindre jeg ønsker det, uanset om jeg kigger i IDE, filsystem eller hvilket værktøj jeg nu bruger.
Windcape (30) skrev:Men i lader jo til at være ligeglad med problemerne, og laver bare et commandline/filsystem fix, hvis Eclipse bugger.
The right tool for the right job. Hvis jeg synes det er nemmest, så er det sådan jeg gør. (Og jeg plejer at integrere det i IDE'et, hvis det er noget jeg skal gøre ofte.)
Hvis du kender en løsning som du bedre kan lide, så brug bare den.
Windcape (31) skrev:Eclipse har 10000 features jeg aldrig kommer til at bruge.
Er det ikke fedt? Når mine behov ændrer sig, kan jeg formentlig stadig bruge Eclipse, fordi de funktioner jeg aldrig skulle bruge før, pludselig bliver vigtige. Godt de er der.
Windcape (34) skrev:Småting som er konstant irreterende ender med at gå en på.
Ja, hvis man ikke kan lære at leve med det. Intet er perfekt.
Så løs problemerne, eller lær at leve med det. Det hjælper ikke at whine.
Windcape (34) skrev:Jeg tester teknologier og sammenligner dem med andre teknologier, og hvordan udviklings processen i disse teknologier foregår.
Det ser ellers ikke sådan ud, set fra vores side. Det ser nærmere ud som om du sammenligner med Microsofts tilsvarende produkter, og så whiner du over ulemperne og ser totalt bort fra fordelene.
Windcape (52) skrev:Jeg whiner ikke, jeg påpeger kritik punkter, som jeg så håber folk kan sige "ah, det kan du løse sådan her".
Men typisk er svaret "vend dig til det!"
Jo, du whiner. Det kan godt være det ikke er intentionen, men det er hvad vi ser.
Når vi så hjælper alligevel, så whiner du videre. Så kan man vælge imellem at sige "lær at leve med det", "hold op med at whine" eller bare holde sin kæft.
Det er sjovt. Jeg skiftede ellers til Java og Elipcse fordi jeg syntes at .NET og Visual Studio var for tunge at arbejde med! :D
Spøg til side... Eclipse kommer med et hav af parametre man kan indstille. Den har fået 2 gb ram at boltre sig med på min maskine, og den flyver som en raket til alt.
Spøg til side... Eclipse kommer med et hav af parametre man kan indstille. Den har fået 2 gb ram at boltre sig med på min maskine, og den flyver som en raket til alt.
#59
Du har det med at møve dig ind på interessante debatter, så at ignorere dig er ikke nogen generel løsning.
Men jeg kan ikke undgå at bemærke at du gør som du plejer: Så meget tekst om hvorfor du har så dårlig success med at få Java/Eclipse til at fungere, og med at få hjælp. Det eneste du reagerer på, er hvad jeg gør. Resten ignoreres, og du lærer formentlig intet af det. Det plejer du i hvert fald ikke.
Du har det med at møve dig ind på interessante debatter, så at ignorere dig er ikke nogen generel løsning.
Men jeg kan ikke undgå at bemærke at du gør som du plejer: Så meget tekst om hvorfor du har så dårlig success med at få Java/Eclipse til at fungere, og med at få hjælp. Det eneste du reagerer på, er hvad jeg gør. Resten ignoreres, og du lærer formentlig intet af det. Det plejer du i hvert fald ikke.
#61
I don't get it. Du har et problem. Der er åbenlyse løsninger, og du kender dem. Du whiner over dit problem. Nogle foreslår nogle af de åbenlyse løsninger. Du whiner over at det ikke fungerer som i et alternativt produkt.
Diskutionen generaliseres, og du påstår at det alternative produkt er åh så meget bedre, bortset fra at du ikke kan bruge det, hvormed det er tydeligt at det overhovedet ikke er bedre når det kommer til stykket.
Jeg forstår ikke hvorfor den måde vi arbejder på ikke er god nok, men du har ikke noget bedre. Vi får tingene til at fungere, og du whiner bare. Og du føler stadig at det er dig der er bedst.
I don't get it. Du har et problem. Der er åbenlyse løsninger, og du kender dem. Du whiner over dit problem. Nogle foreslår nogle af de åbenlyse løsninger. Du whiner over at det ikke fungerer som i et alternativt produkt.
Diskutionen generaliseres, og du påstår at det alternative produkt er åh så meget bedre, bortset fra at du ikke kan bruge det, hvormed det er tydeligt at det overhovedet ikke er bedre når det kommer til stykket.
Jeg forstår ikke hvorfor den måde vi arbejder på ikke er god nok, men du har ikke noget bedre. Vi får tingene til at fungere, og du whiner bare. Og du føler stadig at det er dig der er bedst.
Ja, netop. Der er derfor jeg stiller spørgsmålet.myplacedk (62) skrev:Du har et problem. Der er åbenlyse løsninger, og du kender dem
Åbenlyse løsninger finder jeg med google 5-10 timer før jeg faktisk stiller et spørgsmål.
Jeg laver produktsammenligninger for at folk kan have en ide om hvad der snakkes om. Der er mange udviklere som har erfaring med flere produkter.
Og så bliver folk sure over at jeg nævner at MS produkt, og kalder det whine, og siger man skal tilpasse sig produktet, i stedet for omvendt.
Et udviklingsmiljø skal tilpasses udvikleren, ikke omvendt.
Windcape (63) skrev:Åbenlyse løsninger finder jeg med google 5-10 timer før jeg faktisk stiller et spørgsmål.
5-10 timers forsinkelse gør det ikke bedre.
Windcape (63) skrev:Og så bliver folk sure over at jeg nævner at MS produkt, og kalder det whine,
Det er ikke fordi du nævner MS produkter. Det er fordi det ser ud som om du whiner.
Windcape (63) skrev:og siger man skal tilpasse sig produktet, i stedet for omvendt.
Et udviklingsmiljø skal tilpasses udvikleren, ikke omvendt.
Det hænger altså ikke særligt godt sammen med at du brokker dig over mængden af indstillingsmulighederne, og at du skal benytte dig af dem.
Et eksempel på hvad der får dig til at se så amatør-agtig ud:
"Jeg hader virkelig at Eclipse sletter min kode konstant."
"Eclipse sletter dele af koden ved forkert opsætning af Output Folders i Java Build Path."
"Eclipse synes det er sjovere at slette dem PERMANENT. At flytte dem til papirkurven ville være utrolig behagelig i stedet."
Det er en del af mit job, at rave kastanierne ud af ilden, når folk har skidt i nælderne. Deres IDE er Eclipse/RAD. Jeg har aldrig oplevet nogen komme så galt afsted. Eller gøre noget så dumt, og så give værktøjet skylden. Eller kende flere åbenlyse løsninger, og stadig have et problem.
Windcape (63) skrev:Jeg laver produktsammenligninger for at folk kan have en ide om hvad der snakkes om. Der er mange udviklere som har erfaring med flere produkter.
Wow... arbejder du for DR, for det lyder næsten som public service, det der :)
Windcape (63) skrev:Og så bliver folk sure over at jeg nævner at MS produkt, og kalder det whine, og siger man skal tilpasse sig produktet, i stedet for omvendt.
Nej, folk (eller jeg) bliver ikke sure over at du nævner et MS produkt. Jeg bliver skuffet over at du bliver ved med at vende tilbage til den konklusion at MS er den bedste løsning, da de gør tingene på en måde, og hvis et andet produkt ikke gør det på selvsamme måde - ja, så må det være et ringere produkt.
Windcape (63) skrev:Et udviklingsmiljø skal tilpasses udvikleren, ikke omvendt.
Jamen, så tilpas da blot Eclipse, med den mængde konfigurationsmuligheder der er, skal du nok kunne konfigurere det til dit behov. At antage at Eclipse vil kunne "fornemme" hvad dit behov er, tjaaaah... det grænser til utopi.
#66
Hvordan får du Eclipse til at slette din kode? Nu er jeg ved at være nysgerrig. Hvad skal jeg gøre ved min build path, for at se problemet?
Og i øvrigt: Jeg kan ikke se hvordan det IKKE kan være dit problem. Og hvorfor du brokker dig så meget, hvis det ikke er dit problem.
Hvordan får du Eclipse til at slette din kode? Nu er jeg ved at være nysgerrig. Hvad skal jeg gøre ved min build path, for at se problemet?
Og i øvrigt: Jeg kan ikke se hvordan det IKKE kan være dit problem. Og hvorfor du brokker dig så meget, hvis det ikke er dit problem.
Lidt morsomt.Corholio (65) skrev:Jamen, så tilpas da blot Eclipse, med den mængde konfigurationsmuligheder der er, skal du nok kunne konfigurere det til dit behov.
De få ting jeg synes kunne være rigtig fantastiske at ændre på standardopsætningen, kan ikke lade sig gøre.
F.eks. laver GWT et output af ens entry points til følgende:
war/projectname.EntryPoint/
(En for hvert entry point).
Dem ville jeg gerne skjule, da der er ingen grund til at de er visuelle i Eclipse's Package View. Sådan en mulighed findes åbenbart ikke. (Der er ingen hide eller exclude option, og at sættte 'Derived' virker ikke.).
Jeg kan heller ikke tilpasse autocomplete til at virke på den måde jeg helst ville have (jfh. den anden tråd).
Eclipse's autocompile gør at hot-swap af kode overskriver den forrige WAR package.myplacedk (67) skrev:Hvordan får du Eclipse til at slette din kode? Nu er jeg ved at være nysgerrig. Hvad skal jeg gøre ved min build path, for at se problemet?
Hvilket er et problem, når man nu engang tvinges til at have kode i den, i følge standard strukturen der skal fungere med Eclipse's build system.
Så hvis man laver en forkert opsætning af output folders, så overskriver den de gamle filer, og fjerner dem derfor fra projektet.
Det skulle måske lige siges at IDEA og Netbeans begge to har projekt filer men:
Sidste gang jeg forsøgte at installere Netbeans fik den min CPU til at køre op til 100% til det punkt hvor den låste hele systemet ned. Og konfigurationsmulighederne er næsten lig nul, hvilket gør det utrolig fustrende at benytte. (Jeg gider ikke lære 100 keybindings mere!).
og IDEA, tjah, et billede er værd 1000 ord? Til venstre ses IDEA, til højre Eclipse, med samme XML fil åben: http://clausjoergensen.dk/media/files/idea-vs.png
Sidste gang jeg forsøgte at installere Netbeans fik den min CPU til at køre op til 100% til det punkt hvor den låste hele systemet ned. Og konfigurationsmulighederne er næsten lig nul, hvilket gør det utrolig fustrende at benytte. (Jeg gider ikke lære 100 keybindings mere!).
og IDEA, tjah, et billede er værd 1000 ord? Til venstre ses IDEA, til højre Eclipse, med samme XML fil åben: http://clausjoergensen.dk/media/files/idea-vs.png
Windcape (69) skrev:Eclipse's autocompile gør at hot-swap af kode overskriver den forrige WAR package.
autocompileren laver en WAR-fil, og samme sted placerer du den WAR-fil du laver manuelt?
Windcape (69) skrev:Hvilket er et problem, når man nu engang tvinges til at have kode i den
Du er tvunget til at placere din originale kildekode inde i en WAR-fil?
Windcape (69) skrev:i følge standard strukturen der skal fungere med Eclipse's build system.
Eclipses buildsystem er en del af den standard, som definerer strukturen for en WAR-fil?
Windcape (69) skrev:Så hvis man laver en forkert opsætning af output folders, så overskriver den de gamle filer, og fjerner dem derfor fra projektet.
Så hvis du (ved en fejl) konfigurerer den til at overskrive filer, så gør den det?
Ja, kører en intern jetty. Det ville tage for lang tid at skulle deploy til en lokal server hver gang.myplacedk (71) skrev:autocompileren laver en WAR-fil, og samme sted placerer du den WAR-fil du laver manuelt?
HTML, CSS osv. ja. Det er tiltænkt fra Google's side.myplacedk (71) skrev:Du er tvunget til at placere din originale kildekode inde i en WAR-fil?
Den endelige struktur er bestemt af application serveren, men Eclipse's build system er ikke glad for bestemte path af uransagelige årsager *shrugs*myplacedk (71) skrev:Eclipses buildsystem er en del af den standard, som definerer strukturen for en WAR-fil?
Bortset fra det ikke var en fejl, men en komplet logisk måde at sætte det op på.... udover det faktum at den åbenbart ikke kan lade sig gøre, og resultere i kode tab.myplacedk (71) skrev:Så hvis du (ved en fejl) konfigurerer den til at overskrive filer, så gør den det?
Windcape (68) skrev:Dem ville jeg gerne skjule, da der er ingen grund til at de er visuelle i Eclipse's Package View. Sådan en mulighed findes åbenbart ikke. (Der er ingen hide eller exclude option, og at sættte 'Derived' virker ikke.).
Vrøvl, du klikker på toolbar menuen (den lille hvide trekant, i Package Explorer view part'en), så vælger du "Filters....", herefter klikker du på checkboxen med teksten "Name filter patterns (matching names will be hidden) og skriver "war" i tekstfeltet nedenunder.
Windcape (68) skrev:Jeg kan heller ikke tilpasse autocomplete til at virke på den måde jeg helst ville have (jfh. den anden tråd).
Det har vi vist diskuteret til døde i den anden tråd, Eclipse har implementeret denne funktionalitet på en hvis måde, men du har muligheden for at lave din egen implementation takket være deres plugin-system.
Windcape (69) skrev:Eclipse's autocompile gør at hot-swap af kode overskriver den forrige WAR package.
Hvilket er et problem, når man nu engang tvinges til at have kode i den, i følge standard strukturen der skal fungere med Eclipse's build system.
Så hvis man laver en forkert opsætning af output folders, så overskriver den de gamle filer, og fjerner dem derfor fra projektet.
Det er så også forkert, du er ikke tvunget til at have noget som helst kode liggende i war folderen. Du kan vælge at placere images / css og andet static contents derinde, men den anbefalede struktur ville faktisk være at placere dette i din src-folder, under en "public" folder.
*.html pages, WEB-INF/web.xml mm. bliver ikke slettet under hot-deploy af kode.
Windcape (72) skrev:Bortset fra det ikke var en fejl, men en komplet logisk måde at sætte det op på.... udover det faktum at den åbenbart ikke kan lade sig gøre, og resultere i kode tab.
[sarcasm]
Ja, du har ret.... Google prøver naturligvis kun at håndhæve et totalt irrationelt setup, for at irritere dig. De tog samme beslutning da de skulle vælge hvilket IDE de ville bygge integration til.
[/sarcasm]
Jeg vil ikke skjule hele min war mappe, kun GWT output værdierne (compilede javascript filer for det meste).Corholio (73) skrev:herefter klikker du på checkboxen med teksten "Name filter patterns (matching names will be hidden) og skriver "war" i tekstfeltet nedenunder.
Jeg agter ikke at lave et filter for hvert eneste entry point. Samt at det sikkert vil give problemer da src mappen's struktur jo er cirka den samme.
Det har jeg jo netop ikke. Plugins ystemet er designet til ikke at tillade det :pCorholio (73) skrev:men du har muligheden for at lave din egen implementation takket være deres plugin-system.
Jeg kunne godt få den til at slette det :pCorholio (73) skrev:*.html pages, WEB-INF/web.xml mm. bliver ikke slettet under hot-deploy af kode.
Bortset fra at jeg ikke kan sætte dets output folder til at være /war/ !Corholio (73) skrev:Du kan vælge at placere images / css og andet static contents derinde, men den anbefalede struktur ville faktisk være at placere dette i din src-folder, under en "public" folder.
(Og hvis jeg gør, så begynder den at slette min kode igen.)
#72
That is some really fucked up shit. Enten teknologien eller dig, jeg ved det ikke.
Det må være en GWT-ting
Google beder dig om at placere original kode i en WAR-fil som bliver overskrevet? Det har jeg svært ved at tro. Anyway, tilsyneladende også en GWT-ting.
Aha, en Eclipse-ting! Jeg forstår dog ikke hvad du snakker om. "Bestemte path"? Hvad pokker betyder det? Hvad skal jeg skrive i min build-path, for at se problemet i min Eclipse?
Så du sætter den med vilje til noget forkert, hvor den overskriver noget der ikke skal overskrives, og så er der noget galt med Eclipse når den så gør det?
Jeg er enig med Corholio: Jeg giver op for i aften.
That is some really fucked up shit. Enten teknologien eller dig, jeg ved det ikke.
Windcape (72) skrev:Ja, kører en intern jetty.
Det må være en GWT-ting
Windcape (72) skrev:HTML, CSS osv. ja. Det er tiltænkt fra Google's side.
Google beder dig om at placere original kode i en WAR-fil som bliver overskrevet? Det har jeg svært ved at tro. Anyway, tilsyneladende også en GWT-ting.
Windcape (72) skrev:Eclipse's build system er ikke glad for bestemte path
Aha, en Eclipse-ting! Jeg forstår dog ikke hvad du snakker om. "Bestemte path"? Hvad pokker betyder det? Hvad skal jeg skrive i min build-path, for at se problemet i min Eclipse?
Windcape (72) skrev:Bortset fra det ikke var en fejl
Windcape (72) skrev:myplacedk (71):Så hvis du (ved en fejl) konfigurerer den til at overskrive filer, så gør den det?Bortset fra det ikke var en fejl, men en komplet logisk måde at sætte det op på
Så du sætter den med vilje til noget forkert, hvor den overskriver noget der ikke skal overskrives, og så er der noget galt med Eclipse når den så gør det?
Jeg er enig med Corholio: Jeg giver op for i aften.
moveax1ret (42) skrev:det eneste der er for slow i eclipse er opstart, derfor lukker jeg den aldrigt- problem solved
Corholio (45) skrev:
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.
Det er vist ret normalt.
Det fik vi også forklaret windcape i forrige Eclipse tråd.
Windcape (43) skrev:
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.
Så er der noget helt galt med forståelsen af software udvikling.
Det er kritisk at der bruges det rigtige API.
Kode indtastning er noget som du formodes at bruge 15-30 minutter på om dagen i gennemsnit.
Hvis du sparer 33% så sparer du kun 5-10 minutter om dagen.
Windcape (72) skrev:Ja, kører en intern jetty. Det ville tage for lang tid at skulle deploy til en lokal server hver gang.
Det sekunder det tager at deploye kunne du jo bruge på at tænke over et eller andet design mæssigt eller bare trække vejret dybt et par gange og stresse ned.
Windcape (72) skrev:HTML, CSS osv. ja. Det er tiltænkt fra Google's side.
Nu kender jeg ikke Eclipse GWT plugin, men jeg er nu ret sikker på at original filerne ikke er i en war men kopieres over i en war ved build.
Windcape (72) skrev:Bortset fra det ikke var en fejl, men en komplet logisk måde at sætte det op på.... udover det faktum at den åbenbart ikke kan lade sig gøre, og resultere i kode tab.
Det lyder som en fejl, hvis det resulterer i kode tab.
Det var også min tanke, men Eclipse har ikke support for nested output folders, så det kan åbenbart ikke lade sig gøre.arne_v (81) skrev:Nu kender jeg ikke Eclipse GWT plugin, men jeg er nu ret sikker på at original filerne ikke er i en war men kopieres over i en war ved build.
Min ide til opsætning:
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
<classpathentry kind="src" path="src"/>
<classpathentry kind="src" output="war" path="www"/>
<classpathentry kind="con" path="com.google.appengine.eclipse.core.GAE_CONTAINER"/>
<classpathentry kind="con" path="com.google.gwt.eclipse.core.GWT_CONTAINER"/>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
<classpathentry kind="con" path="org.eclipse.jdt.USER_LIBRARY/GXT"/>
<classpathentry kind="output" path="war/WEB-INF/classes"/>
</classpath>
Med følgende folder struktur: http://dl.dropbox.com/u/1744224/Upload/gxtprobl1.p...
Men nu brokker Eclipse sig bare over at web.xml og app-engine-web.xml ikke findes , fordi de ikke er kopieret over korrekt.
Samt at der bliver slet ikke kopieret nogen .class filer over overhovedet!
#83
Alt kompileret Java (.class) skal ind i /war/WEB-INF/classes/
Alle classpath libs (.jar) skal ind i /war/WEB-INF/lib/
Alt client-indhold (.html, .css, .js) skal ind i /war/
Men Eclipse tillader det ikke. Den siger at jeg ikke må neste folders. Det er forvirrende, fustrerende og giver overhovedet ingen mening.
Alt kompileret Java (.class) skal ind i /war/WEB-INF/classes/
Alle classpath libs (.jar) skal ind i /war/WEB-INF/lib/
Alt client-indhold (.html, .css, .js) skal ind i /war/
Men Eclipse tillader det ikke. Den siger at jeg ikke må neste folders. Det er forvirrende, fustrerende og giver overhovedet ingen mening.
Det underlige er også at ligeså snart jeg vælger mere end én output folder, så laver Eclipse ikke deploy af .class og .jar filer.
Måske skulle jeg bare give op på Eclipse's standardsystem, og lære ANT i stedet.
Det ville bare være ret træls, da det ødelægger enhver mulighed for hot swap af kode, hvilket sløver udviklingen ekstremt meget.
Måske skulle jeg bare give op på Eclipse's standardsystem, og lære ANT i stedet.
Det ville bare være ret træls, da det ødelægger enhver mulighed for hot swap af kode, hvilket sløver udviklingen ekstremt meget.
#Eclipse problemer & strategi for løsning versus whining
Du har tilsyneladende en del Eclipse problemer.
Du får overskrevet noget der ikke skal overskrives.
Din Eclipse virker lidt bloatet (kontekst menu størrelse og mulige key binding er større end normalt).
Andre Eclipse brugere synes ikke at have disse problemer.
Men dem som bruger Eclipse på arbejde fungerer i en helt anden kontekst. De arbejder typisk med det samme (samme sprog og framework) i mange år. De har mange års erfaringmed Eclipse. De har et større antal kolleger som også bruger Eclipse tild et samme og kan give gode hints. Formentligt har firmaet en standard opsætning af Eclipse som er tilpasset den ting firmater arbejder med - en opsætning som der faktisk er nogen som har ansvar for at holde opdateret.
Du kommer derimod vidt omkring. Du laver JSF i sommeren, noget ikke-Java i efteråret og GWT om vinteren.
Det er meget fint. Du er studerende og det er godt at lære en masse.
Men du skal nok gribe det lidt anderledes an.
Plugins.
1) Der er i tusindvis af Eclipse plugins. Google dem og læs hvad folk synes om dem.
2) Spørg om anbefalinger. Folk kan godt blive lidt trætte af "Eclipse sucks" tråde. Men "Vil folk anbefale den indbyggede CVS eller SVN plugin X eller SVN plugin Y og hvorfor?" skal nok få nogle seriøse svar på banen.
3) Eksperimenter. Lav 2 Eclipse instanser: eclipse-gwt-experiment og eclipse-gwt-work. I eclipse-gwt-experiment installerer du alle de plugins du har lyst til at teste og se hvordan de virker. I eclipse-gwt-work installerer du de plugins som du beslutter dig for at bruge laver du dit GWT arbejde. Når eclipse-gwt-experiment er totalt fucked up, så sletter du det bare og udpakker en ny jomfruelig Eclipse og starter forfra.
Projekt opsætning.
Det samme.
1) Læs om hvad andre bruger. Nogen gange er man heldige og der er deciderede GUI vejledninger med screen shots.
2) Spørg hvad folk gør.
3) Eksperimenter. Enten i experiement eclipse eller i et scratch projekt i work eclipse.
Min vurdering er at skal du arbejde med noget som er udover et helt almindeligt standard SE projekt, så vil det være en god investering at bruge noget tid på at finde det rigtige setup.
Det er det firmaer gør. De har ikke en krystal kugle hvor udviklerne lige kan se hvilke plugins de skal hente og sætte op hvordan. De udnytter mange års erfaring til at få tingene gjordt optimalt til deres behov.
Du har tilsyneladende en del Eclipse problemer.
Du får overskrevet noget der ikke skal overskrives.
Din Eclipse virker lidt bloatet (kontekst menu størrelse og mulige key binding er større end normalt).
Andre Eclipse brugere synes ikke at have disse problemer.
Men dem som bruger Eclipse på arbejde fungerer i en helt anden kontekst. De arbejder typisk med det samme (samme sprog og framework) i mange år. De har mange års erfaringmed Eclipse. De har et større antal kolleger som også bruger Eclipse tild et samme og kan give gode hints. Formentligt har firmaet en standard opsætning af Eclipse som er tilpasset den ting firmater arbejder med - en opsætning som der faktisk er nogen som har ansvar for at holde opdateret.
Du kommer derimod vidt omkring. Du laver JSF i sommeren, noget ikke-Java i efteråret og GWT om vinteren.
Det er meget fint. Du er studerende og det er godt at lære en masse.
Men du skal nok gribe det lidt anderledes an.
Plugins.
1) Der er i tusindvis af Eclipse plugins. Google dem og læs hvad folk synes om dem.
2) Spørg om anbefalinger. Folk kan godt blive lidt trætte af "Eclipse sucks" tråde. Men "Vil folk anbefale den indbyggede CVS eller SVN plugin X eller SVN plugin Y og hvorfor?" skal nok få nogle seriøse svar på banen.
3) Eksperimenter. Lav 2 Eclipse instanser: eclipse-gwt-experiment og eclipse-gwt-work. I eclipse-gwt-experiment installerer du alle de plugins du har lyst til at teste og se hvordan de virker. I eclipse-gwt-work installerer du de plugins som du beslutter dig for at bruge laver du dit GWT arbejde. Når eclipse-gwt-experiment er totalt fucked up, så sletter du det bare og udpakker en ny jomfruelig Eclipse og starter forfra.
Projekt opsætning.
Det samme.
1) Læs om hvad andre bruger. Nogen gange er man heldige og der er deciderede GUI vejledninger med screen shots.
2) Spørg hvad folk gør.
3) Eksperimenter. Enten i experiement eclipse eller i et scratch projekt i work eclipse.
Min vurdering er at skal du arbejde med noget som er udover et helt almindeligt standard SE projekt, så vil det være en god investering at bruge noget tid på at finde det rigtige setup.
Det er det firmaer gør. De har ikke en krystal kugle hvor udviklerne lige kan se hvilke plugins de skal hente og sætte op hvordan. De udnytter mange års erfaring til at få tingene gjordt optimalt til deres behov.
Windcape (84) skrev:
Alt kompileret Java (.class) skal ind i /war/WEB-INF/classes/
Alle classpath libs (.jar) skal ind i /war/WEB-INF/lib/
Alt client-indhold (.html, .css, .js) skal ind i /war/
Men Eclipse tillader det ikke. Den siger at jeg ikke må neste folders. Det er forvirrende, fustrerende og giver overhovedet ingen mening.
Nu kender jeg ikke GWT plugin, men normalt har Eclipse benhård adskillese af source og output.
Jeg tror at der er truffet nogle forkerte valg med hensyn til opsætning af projektet.
Jeg forsøger at finde ud af præcist hvad der går galt.arne_v (87) skrev:Jeg tror at der er truffet nogle forkerte valg med hensyn til opsætning af projektet.
Problemet lader til at være at Eclipse ikke kan håndtere 2 forskellige "Output Locations" i dens Build Path.
Den ignorer simpelthen output-location for /src/ totalt.
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
<classpathentry kind="src" path="src"/>
<classpathentry kind="src" output="war" path="www"/>
<classpathentry kind="con" path="com.google.appengine.eclipse.core.GAE_CONTAINER"/>
<classpathentry kind="con" path="com.google.gwt.eclipse.core.GWT_CONTAINER"/>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
<classpathentry kind="con" path="org.eclipse.jdt.USER_LIBRARY/GXT"/>
<classpathentry kind="output" path="war/WEB-INF/classes"/>
</classpath>
The project was not built due to "Resource '/gxt-mail/war/WEB-INF/classes' does not exist.". Fix the problem, then try refreshing this project and building it since it may be inconsistent.
arne_v (92) skrev:Er der nogen som har et fungerende Eclipse GWT projekt opsætning som de kan dele??
Da ejg arbejdede med GWT brugte jeg bare den første tutorial jeg fandt, kørte "Hello World"-projektet igennem, og så startede jeg mit eget projekt. Det fungerede glimrende, med hot swap osv. Jeg endte dog med at droppe GWT igen, så jeg har ikke lige noget jeg kan finde frem.
#93
Men netop standard opsætningen redigere du .html osv. direkte i war pakken! Hvilket det hele tiden har gået på at undgå.
Jeg har fundet en underlig løsning på problemet med 2 output folders.
Hvis jeg laver WEB-INF/classes/ mappen og placere en dummy.txt fil i den, så kan Eclipse lige pludselig godt finde ud af at kopiere data over.
Men hvis mappen ikke findes, eller er tom, så bliver den ikke oprettet af builderen!
Men netop standard opsætningen redigere du .html osv. direkte i war pakken! Hvilket det hele tiden har gået på at undgå.
Jeg har fundet en underlig løsning på problemet med 2 output folders.
Hvis jeg laver WEB-INF/classes/ mappen og placere en dummy.txt fil i den, så kan Eclipse lige pludselig godt finde ud af at kopiere data over.
Men hvis mappen ikke findes, eller er tom, så bliver den ikke oprettet af builderen!
Og følgende opsætning virker: http://dl.dropbox.com/u/1744224/Upload/virker.png
Jeg har en .classes fil liggende i min /classes/ mappe, med en advarsel om at den ikke må slettes. Det virker som det bedste løsning, indtil/hvis jeg går over til ANT i stedet.
Og det løser problemerne med versions-styring.
Jeg har en .classes fil liggende i min /classes/ mappe, med en advarsel om at den ikke må slettes. Det virker som det bedste løsning, indtil/hvis jeg går over til ANT i stedet.
Og det løser problemerne med versions-styring.
#whine
Når jeg går tråden igennem har tonen ikke været helt i orden, det vil jeg så undskylde.
Overordnet har problemet som har været utrolig svært at forklare, baseret sig et problem med standard build-systemet i Eclipse, som jeg kan forstå på folk, typisk hurtigt erstattes af ANT i sådanne situationer.
Så jeg vil alligevel sig tak for alles input.
Når jeg går tråden igennem har tonen ikke været helt i orden, det vil jeg så undskylde.
Overordnet har problemet som har været utrolig svært at forklare, baseret sig et problem med standard build-systemet i Eclipse, som jeg kan forstå på folk, typisk hurtigt erstattes af ANT i sådanne situationer.
Så jeg vil alligevel sig tak for alles input.
#Eclipse & GWT plugin
Nu prøvede jeg lige selv at lege lidt med det.
Så vidt jeg kan se er der 2 måder at gøre det på:
1) den måde som GWT folkene tilsyneladende ønsker det
src : Java kode
war/<modul> : nix pille
war/WEB-INF : nix pille
war og war/<alt-andet-end-modul-og-web-inf> : static content
og byg med den GWT compiler external tool som plugin installerer
2) DIY med ant
src : Java kode
static : static content
war : nix pille
og byg med ant og en build.xml som kan se ud som:
Nu prøvede jeg lige selv at lege lidt med det.
Så vidt jeg kan se er der 2 måder at gøre det på:
1) den måde som GWT folkene tilsyneladende ønsker det
src : Java kode
war/<modul> : nix pille
war/WEB-INF : nix pille
war og war/<alt-andet-end-modul-og-web-inf> : static content
og byg med den GWT compiler external tool som plugin installerer
2) DIY med ant
src : Java kode
static : static content
war : nix pille
og byg med ant og en build.xml som kan se ud som:
<?xml version="1.0" encoding="UTF-8"?>
<project name="gwt via ant" default="all">
<property name="gwt.root" value="C:/DivJava/gwt-2.0.0"/>
<property name="my.package" value="test"/>
<property name="my.module" value="test2"/>
<property name="web.app" value="C:/gwt-test.war"/>
<path id="gwt.libs">
<fileset dir="${gwt.root}">
<include name="**/*.jar"/>
</fileset>
</path>
<target name="precopy">
<copy todir="war">
<fileset dir="static"/>
</copy>
</target>
<target name="javacompile">
<javac classpathref="gwt.libs"
srcdir="src"
destdir="war/WEB-INF/classes"/>
</target>
<target name="gwtcompile">
<java classpathref="gwt.libs"
classpath="src"
fork="true"
classname="com.google.gwt.dev.Compiler">
<arg line="${my.package}.${my.module}"/>
</java>
</target>
<target name="all" depends="precopy,javacompile,gwtcompile"/>
<target name="export" depends="all">
<zip destfile="${web.app}"
basedir="war"/>
</target>
</project>
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