Efter det att jag uppgraderat till Ubuntu 9.10 så uppstod det lite problem med min Eclipse 3.5 installation, vissa knappar i olika dialoger slutade att fungera. Efter en snabb googling så visade det sig att det är en bug i Eclipse som är fixad i Eclipse 3.6 M2. För att få Eclipse 3.5 att fungera i Ubuntu 9.10 så kan man starta Eclipse med följande lilla skript:
#!/bin/sh
export GDK_NATIVE_WINDOWS=1
/path/to/your/eclipse/installation/dir/eclipse
Vi har tidigare diskuterat lite sköna snabbkommandon för Eclipse i inlägget Eclipse Tips och Tricks. Då nämndes bland annat Ctrl-Shift+F för att formatera koden och Ctrl+Shift+O för att organisera importer.
I Eclipse finns något som kallas för Save Actions under Window -> Preferences och sedan Java -> Editor -> Save Actions. Där kan man ställa in en hel del saker som automatiskt ska ske när du sparar en fil exempelvis:
Om du gillar att ha ordning och reda i dina källkodsfiler kan jag rekommendera detta. Det är dock viktigt att man bestämmer vilka formateringsregler som ska gälla i det aktuella projektekt och att alla använder dessa regler. Annars kan filerna förändras för mycket mellan varje incheckning. Om någon exempelvis använder tabbar och någon annan använder mellanslag så kommer filerna att diffa stort fast man kanske bara har gjort en mindre förändring.
Självklart kan detta arbetssätt vara problematiskt ifall du sitter i en existerande kodbas som inte är bra formaterad – varje ”Save” kan leda till att den aktuella filen förändras kraftigt på grund av formateringen och det kan det bli svårt att se vad som egentligen förändrats i filen mellan två versioner. Detta är ju dock ett problem som försvinner över tiden eftersom alla filer så småningom är formaterade.
Vid problem i en lokal miljö finns det flera kraftfulla verktyg att ta till i form av profilerare och debuggers. När det stökar i en produktionsmiljö är det lite värre då man vill undvika att påverka prestanda. Ett hangrepp som man med gott samvete kan ta till i de aldra flesta produktionsmiljöer är tråddumpning Läs mer >>
Denna artikel ingår i serien Spring från början och kommer behandla det springstöd som finns för OSGi. Denna artikel är inte direkt en ”tutorial” utan ger främst en orientering till OSGi och Spring Dynamic Modules och gör ett försök till att peka på lämpliga användningsområden.
Förkortningen , vilket i vart fall inte hjälper mig att förstå vad OSGi egentligen är.
OSGi står tydligen för Open Service Gateway Initiative, men det har inte hjälpt någon att förstå vad det OSGi egentligen är får något. OSGi-standarden är helt kort en standard för modularisering av javaapplikationer.
OSGi används i allt från inbäddade system, mobiltelefoner till en flerskiktade webbapplikationer. Standarden har funnits i flera år och har tidigare främst används i inbäddade system. Det är först på senare år som OSGi har blivit aktuellt att använda i serverapplikationer. Den kanske mest kända applikationen som bygger på OSGi är den populära utvecklingsmiljön Eclipse, som använder OSGi i sitt plug-in system.
Mer konkret så specificerar standarden tre områden; paketering av moduler, tjänsteregister och modulers livscykler. Läs mer >>
Eclipse Foundation har nu släppt sin årliga samling av projekt som i år fått namnet Eclipse Ganymede. I år så innehåller samlingen 23 st olika projekt. Här kan du läsa mer och även ladda ner Eclipse Ganymede.
Häromdagen råkade jag hitta eclipse-pluginen q4e som gör att du kan använda Maven 2 från Eclipse IDE. Projektet huserar på Google Code och några av de features som nämns är:
Pluginen har väldigt många av de features som finns i pluginen m2eclipse som jag tidigare skrivit om här. Efter att ha labbat lite med pluginen så har jag fått känslan av att q4e är stabilare, rappare och snyggare än m2eclipse, dock krävs Eclipse 3.3 (m2eclipse går att köra på Eclipse 3.2). För mer information gällande q4e rekommenderar jag deras wiki och denna jämförelse mellan m2eclipse och q4e.
För någon månad sedan så tipsade jag om ett litet verktyg som jag hade stött på, jarjar. Nu tänkte jag tipsa om en plugin till Eclipse som gör samma sak, packar ihop din applikation till en enda jarfil med alla beroenden från alla externa bibliotek som du använder. Pluginen heter Fat Jar och kan laddas ner här. Eclipse 3.0 eller nyare krävs.
(Texten som tidigare saknades i detta blogginlägg är nu återskapad.)
Som en fortsättning på min artikel Eclipse Tips och Tricks, och Tommys Breakpoints i Eclipse, så tänkte jag berätta lite om remote-debuggning i Eclipse. Det är en mycket användbar teknik att kunna.
Det finns en massa bra pluginer till Eclipse för att hantera utveckling med olika applikationsservrar och servlet-motorer. Men i många fall behövs inte dessa. Java har länge kunnat öppna en port i VMen för att tillåta en debugger att koppla upp sig. Med Eclipse är det mycket enkelt. Se här bara…
Breakpoints är ett ovärderligt verktyg när det gäller att debugga kod. I Eclipse (och förmodligen andra IDE:s) så kan man även sätta breakpoints som baseras på ”conditions” och ”exceptions”.
Efter en lunchdiskussion med ett par av mina kollegor letade jag fram ett gammalt dokument som jag skrev åt en kund för ett par år sedan. Det hade titeln ”Eclipse Tips och Tricks”. Det är tyvärr inte up-to-date längre, så jag tänker inte dela med mig av det här, men det väckte en del tankar.
Det kan göra rätt stor skillnad på produktiviteten att lära sig några nyckelfinesser i det verktyg man använder sig av — särskilt om det är det verktyg man jobbar större delen av dagarna med som Eclipse tenderar att vara för Java-utvecklare. Ändå händer det allt som oftast att man ser någon göra nån liten grej som man aldrig sett förut.
För skojs skull tänkte jag därför försöka lista de vanligast handgreppen jag gör i Eclipse. Antagligen känner du till de flesta, men kanske är det något som är nytt. Och säkert kan du tipsa mig (i kommentarerna) om något smart som jag borde känna till!
