Auf dem Mac gibt es folgendes Problem: The JVM shared library "/Library/Java/JavaVirtualMachines/openjdk ... " does not contain the JNI-CreateJavaVM symbol.
Scheinbar kollidieren OpenJDK 7 und Oracle JDK. Durch das löschen des OpenJDK kann das Problem gelöst werden:
sudo rm -rf /Library/Java/JavaVirtualMachines/openjdk-1.7-x86_64
Posts mit dem Label Eclipse werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Eclipse werden angezeigt. Alle Posts anzeigen
Montag, 12. November 2012
Mittwoch, 24. Oktober 2012
Maven Basiskonfiguration
Mit Maven 3 hat sich einiges in den Default-Werten geändert. Trotzdem muss man das JDK und das Encoding explizit in der POM Datei angeben:
Auch ja, und im PMD Plugin sollten auch die richtige JDK Version gesetzt sein:
...
<properties>
<jdk.version>1.7</jdk.version>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<organization>
...
</project>
![]() |
| So sehen dann die Einstellung zum JDK und zum Encoding in Eclipse aus. |
...
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>2.5</version>
<configuration>
<linkXref>true</linkXref>
<minimumTokens>100</minimumTokens>
<minimumPriority>5</minimumPriority>
<targetJdk>1.7</targetJdk>
</configuration>
</plugin>
</reportPlugins>
</configuration>
</plugin>
</plugins>
</build>
Mittwoch, 15. August 2012
Java 7 konfigurieren unter Mac OS X und Eclipse
Java 7 ist endlich für Mac OS X fertig geworden.
Aber wie konfiguriert man Eclipse bzw. STS, dass es das neue Java 7 verwendet. Dazu muss man zuerst das neue Java finden (/Library/Java/JavaVirtualMachines/jdk1.7.0_07.jdk/Contents/Home/). Leider kann man diesen Ordner nicht im Eclipse Filechooser auswählen, man muss den Pfad direkt in die Zeile JRE home rein kopieren (siehe Bild unten).
Jetzt muss nur noch ein guter JRE name gesetzt werden. Leider funktioniert dieser Trick bei Open Office nicht.
Damit Maven auch das neue Java 7 benutzt muss die Variable Java_Home gesetzt werden. Am besten editiert man dazu die ~/.profile. Dort fügt man folgende Zeile ein:
export JAVA_HOME="/Library/Java/JavaVirtualMachines/jdk1.7.0_11.jdk/Contents/Home"
Dann benutzt Maven auch das aktuelle Java:
mvn -version
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /usr/share/maven
Java version: 1.7.0_11, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_11.jdk/Contents/Home/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "mac os x", version: "10.8.3", arch: "x86_64", family: "mac"
- JRE: http://www.oracle.com/technetwork/java/javase/downloads/jre7-downloads-1637588.html
- JDK: http://www.oracle.com/technetwork/java/javase/downloads/jdk7u7-downloads-1836413.html
Aber wie konfiguriert man Eclipse bzw. STS, dass es das neue Java 7 verwendet. Dazu muss man zuerst das neue Java finden (/Library/Java/JavaVirtualMachines/jdk1.7.0_07.jdk/Contents/Home/). Leider kann man diesen Ordner nicht im Eclipse Filechooser auswählen, man muss den Pfad direkt in die Zeile JRE home rein kopieren (siehe Bild unten).
Jetzt muss nur noch ein guter JRE name gesetzt werden. Leider funktioniert dieser Trick bei Open Office nicht.
Damit Maven auch das neue Java 7 benutzt muss die Variable Java_Home gesetzt werden. Am besten editiert man dazu die ~/.profile. Dort fügt man folgende Zeile ein:
export JAVA_HOME="/Library/Java/JavaVirtualMachines/jdk1.7.0_11.jdk/Contents/Home"
Dann benutzt Maven auch das aktuelle Java:
mvn -version
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /usr/share/maven
Java version: 1.7.0_11, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_11.jdk/Contents/Home/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "mac os x", version: "10.8.3", arch: "x86_64", family: "mac"
Donnerstag, 25. November 2010
Au weia, ich habe die falsche Datei überschrieben ...
was nun, ich habe eine wichtige Datei im Projekt überschrieben und im Subversion liegt auch nur eine alte Version. Eclipse liegt lokale Kopien von den Daten an die man bearbeitet. Wenn man eine solche lokale Kopie wiederherstellen will, muss man im Package Explorer einen Rechtsklick auf die Datei machen und dann in das Menü Restore from Local History ... (siehe Bild).
Damit hat man das erste Problem gelöst, aber da hinter jedem kleinen Problem ein grosses Problem steckt, muss auch dieses Problem gelöst werden. Es zeigt sich also, dass die Richtlinien fürs Codemanagement unvollständig sind oder unzureichend umgesetzt werden. In der Regel gilt, nach jeden Bug Fixing, nach jeden Feature oder nach jedem Refactoring sollte das SVN Repository aktualisiert werden. Übrigens kann man auch sehr einfach ein lokales SVN aufsetzen (Setup a Subversion Server in 4 Minutes). Wenn sich dies nur schwierig im eigenen Entwicklungsprozess umsetzen lässt, dann sollte man einen Blick auf Git werfen.
Damit hat man das erste Problem gelöst, aber da hinter jedem kleinen Problem ein grosses Problem steckt, muss auch dieses Problem gelöst werden. Es zeigt sich also, dass die Richtlinien fürs Codemanagement unvollständig sind oder unzureichend umgesetzt werden. In der Regel gilt, nach jeden Bug Fixing, nach jeden Feature oder nach jedem Refactoring sollte das SVN Repository aktualisiert werden. Übrigens kann man auch sehr einfach ein lokales SVN aufsetzen (Setup a Subversion Server in 4 Minutes). Wenn sich dies nur schwierig im eigenen Entwicklungsprozess umsetzen lässt, dann sollte man einen Blick auf Git werfen.
Freitag, 24. September 2010
R Plugin für Eclipse
Auch für gibt es ein Eclipse-Plugin. Hier beschreibe ich wie ich eine funktionierende R Installation mittel StatET-Plugins in Eclipse nutze.
- Installation von SatET via Update-Site
- Konfigurieren des Proxys für R in der Konsole: export http_proxy=http://proxy:8080
- Starte von R in der Konsole: R
- Installation des R-Paketes rJava: install.packages('rJava')
- Laden des Paktes rJava: library(rJava)
- Testen des Pakets und Beenden von R: q()
- Download des rj Paketes mit dem Webbrowser
- Installation des rj Paketes in der Konsole: R CMD INSTALL --no-test-load rj_0.5.0-5.tar
- Konfiguration von StatET in Eclipse
Mittwoch, 23. Juni 2010
Eclipse Helios
Die kommende Eclipse Helios (Eclipse 3.6) hat ein neues Feature, auf das Viele schon lange gewartet haben. Im Package Explorer werden nicht mehr die vollen Packagenamen angezeigt, sondern sie werden jetzt verkürzt dargestellt. Dies spart Platz auf dem Bildschirm. Wie das aussieht ist hier in der Abbildung 6 zu sehen. Leider werden die Namen nicht automatisch gekürtzt, sondern man muss manuell ein Mapping anlegen. Damit ist dies Funktion nur noch halb so elegant.
Elipse Helios Download Link.
Elipse Helios Download Link.
Mittwoch, 26. Mai 2010
Neue Version des Eclipse LaTeX-Plugins, Texlipse 1.4 erschienen
Wir haben schon lange auf eine neue Version von Texlipse gewartet, endlich ist sie da. Neu ist, dass es eine LaTeX-Perspektive gibt, und man sie sich nicht mehr selber bauen muss. Vor allem wurden auch Bugs gefixt. Ich werde die neue Texlipse-Version bei Gelegenheit testen.
Update-Site:
http://texlipse.sourceforge.net/
Update-Site:
http://texlipse.sourceforge.net/
Mittwoch, 7. April 2010
Mixt it oder auch nicht - die 32 Bit Java Option
Ich habe auf meinem Mac ein aktuelles Eclipse, die Mac Cocoa 64 Bit Version. Jetzt versuchte ich ein eigenes Eclipse-Plugin zu entwickeln und erzeugte ein entsprechendes neues Projekt. Wow, ein seltsamer Fehler in der .log Datei: java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on 64-bit JVM.
Was nun, die Tipps wie der auf Seite SWT FAQ fruchten nicht oder waren zu kompliziert. Einfacher war es beim Start meines Plugins die 32 Bit Karte zu ziehen. Mit Hilfe der VM-Option -d32 weist man die JVM an das 32 Bit Datenmodell zu benutzen. Dies muss man in Eclipse bei Run Configurations ... / Arguments / VM Arguments eintragen.
Neben der VM-Option -d32 gibt es auch die 64 Bit Option -d64. Und wenn die Ergebnisse aus der Veröffentlichung von Venstermans, Eeckhout und De Bosschereaus aus dem Jahr 2005 noch heute stimmen, sollte man in der Regel bei der 32 Bit Option bleiben. Das 64 Bit Java verbraucht mehr Heap (39%), führt zu mehr Cache Misses und ist auch noch langsamer (1,7%).
Update: Diese Informationen sind für Java 7 nicht mehr zutreffend. In Java 7 gibt es eine Option die den 64 Bit Overhead reduziert.
Was nun, die Tipps wie der auf Seite SWT FAQ fruchten nicht oder waren zu kompliziert. Einfacher war es beim Start meines Plugins die 32 Bit Karte zu ziehen. Mit Hilfe der VM-Option -d32 weist man die JVM an das 32 Bit Datenmodell zu benutzen. Dies muss man in Eclipse bei Run Configurations ... / Arguments / VM Arguments eintragen.
Neben der VM-Option -d32 gibt es auch die 64 Bit Option -d64. Und wenn die Ergebnisse aus der Veröffentlichung von Venstermans, Eeckhout und De Bosschereaus aus dem Jahr 2005 noch heute stimmen, sollte man in der Regel bei der 32 Bit Option bleiben. Das 64 Bit Java verbraucht mehr Heap (39%), führt zu mehr Cache Misses und ist auch noch langsamer (1,7%).
Update: Diese Informationen sind für Java 7 nicht mehr zutreffend. In Java 7 gibt es eine Option die den 64 Bit Overhead reduziert.
Sonntag, 28. März 2010
M2Eclipse Version 0.10.0
Eine neue Version des beliebten Eclipse-Maven-Plugins m2eclipse ist erschienen. Für alle Eclipse Benutzer die eine vorhergehende Version von m2eclipse einsetzen, müssen sie als erstes das alte Plugin deinstallieren und anschliessend die neuen Version installieren. Die Aktualisierung per Updatesite URL funktioniert nicht. Das liegt daran, das es mit der Version 0.10.0 zwei neue Updatesite URLs vorhanden sind. Das Plugin besteht jetzt aus zwei Teilen dem Core-Plugin und den Extras. Um alle Extras installieren zu können sollte vor der Installation von M2Eclipse Subclipse installiert werden.
http://m2eclipse.sonatype.org/sites/m2e-extras
Und natürlich sollte man auch gleich den Proxy-Eintrag für Maven konfigurieren: http://maven.apache.org/guides/mini/guide-proxies.html
http://m2eclipse.sonatype.org/sites/m2e-extras
Und natürlich sollte man auch gleich den Proxy-Eintrag für Maven konfigurieren: http://maven.apache.org/guides/mini/guide-proxies.html
Donnerstag, 25. Juni 2009
Wo sollen die JUnit-Tests ausgeführt werden?
Wenn man ein Projekt mit Hilfe Mavens realisiert, steht man meist vor der Frage wo man die JUnit-Tests ausführt. Natürlich in Maven, das funktioniert prima auf Grund der meist durch Maven definierten Projektstruktur (ich weiss, sie ist natürlich änderbar). Das Problem was ich dann habe, es dauert länger bis ich weiss wie das Ergebnis der Test ist, dazu kommt das die Integration der Testergebnisse und deren graphische Darstellung (lange List in der Console) im Vergleich zur JUnit-Komponnente aus Eclipse mau ist. Wenn ich versuche einzelne Tests oder alle Tests des Projekts via Run-Menü in Eclipse ausführen zu lassen schlägt dies fehl. Abhilfe schafft dort ein anderer Weg (siehe Bild), wähle im Package Explorer das Projekt aus, gehe dann auf den Menüpunkt Run As und dort weiter auf den Punkt 5 JUnit Test. Das wars, jetzt können alle Tests sowohl in Maven als auch in Eclipse ausgeführt werden.

Dienstag, 21. April 2009
Texlipse
Zur Zeit erstelle ich ein Liste meiner Programmierwerkzeuge. Heute ist der Abschnitt zu Texlipse fertig geworden. Teclipse ist ein Eclipse-Plugin zur Erstellung von Latex-Dokumenten. Weiters ist hier zu finden: http://sites.google.com/site/mirkoebert/Home/werkzeuge
Montag, 6. April 2009
Maven 2
Wer mit Maven arbeitet, kommt nicht umhin Jar's zu ins eigenen Projekt zu integrieren, die nicht im zentralen Repository zu finden sind. Um solche fremden Pakete (Jar's) in eigene Repository (/Users/ebert/.m2) zu integrieren benötigt man nicht eine eigene Maven-Installation. Klassischer Wiese braucht man eine Maven-Installation und führt dann in der Shell folgenden Befehl aus: mvn install:install-file -DgroupId=java.plugin -DartifactId=plugin -Dversion=jre-1.5 -Dpackaging=jar -Dfile=/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home/lib/plugin.jar -- jetzt ist das betreffende Jar registriert.
Wenn man mit Eclipse arbeitet kann man das auch ohne zweite Maven-Installation machen. Eclipse bringt Maven schon mit. So kann man z.B: install:install-file -DgroupId=java.plugin -DartifactId=plugin -Dversion=jre-1.5 -Dpackaging=jar -Dfile=/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home/lib/plugin.jar direkt im Run-Dialog unter Goals von Maven eingeben. Dieser Dialog ist eigentlich nicht für diese Verwendung gedacht, funktioniert aber.
Wenn man mit Eclipse arbeitet kann man das auch ohne zweite Maven-Installation machen. Eclipse bringt Maven schon mit. So kann man z.B: install:install-file -DgroupId=java.plugin -DartifactId=plugin -Dversion=jre-1.5 -Dpackaging=jar -Dfile=/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home/lib/plugin.jar direkt im Run-Dialog unter Goals von Maven eingeben. Dieser Dialog ist eigentlich nicht für diese Verwendung gedacht, funktioniert aber.
Abonnieren
Kommentare (Atom)



