RCP Compilereinstellungen festlegen bei Eclipse-Batch-Build

[tfa]

Wir bauen unser Projekt seit kurzem automatisch über Hudson/Buckminster. Das funktioniert mittlerweile super, allerdings schaffe ich es nicht, die Compilereinstellungen zu setzen.
Ich würde gerne die Compiler-Warnungen (teilweise) deaktivieren, denn in unseren Sourcen gibt es viele Altlasten (Raw-Type usw.).
Ich habe versuchsweise in den build.properties "compilerArg" hinzugefügt:

source.. = src/
output.. = bin/
javacSource = 1.5
javacTarget = 1.5
compilerArg = -nowarn

Leider hat das keine Auswirkungen auf die vom Compiler produzierten Warnungen.
Wo muss ich das einstellen? Weiß jemand Rat?

 

[SlaterB]

Anführungszeichen oder Leerzeichen weglassen?
[news.eclipse.platform] Re: Specifying compilerArg in build.properties f

 

[tfa]

Danke für den Tipp. Hat leider aber auch nicht geklappt. Keine Änderung. Ich frag mich, ob diese build.properties-Datei überhaupt eine Auswirkung hat.

 

[Wildcard]

Da du Buckminster verwendest geht das ganz einfach:
In den Project Properties musst du die Project Specific Settings für Compiler Warnings aktivieren.
Dort stellst du alles so ein wie du es gern haben würdest und commitest dann die .settings ins Versionskontrollsystem. Buckminster wird diese EInstellungen dann automatisch verwenden.
Wenn du aus welchem Grund auch immer keine Project Specific Settings verwenden möchtest musst du mit einem Template Workspace arbeiten (siehe Bucky Book).

 

[tfa]

Danke für den Hinweis. Das klingt interessant. Da wir ca. 40 Eclipse-Projekte haben, denen ich nicht jeweils eigene Settings geben will, habe ich es mit dem Template Workspace ausprobiert.

Hierzu habe ich einen frischen Eclipse-Workspace angelegt und die Compiler-Einstellungen entsprechend angepasst. Diesen WS habe ich auf den Hudson-Server kopiert.
An der Kommando-Zeile funktioniert schonmal der Import:

./buckminster -data /pfad/zum/workspace  import --template /pfad/zum/template_workspace /pfad/zur/cquery

Im Hudson erscheint leider folgender Fehler:

+ ls -lisa /pfad/zum/workspace/
ls: + true
cannot access /pfad/zum/workspace/: No such file or directory
[workspace] $ /usr/lib/jvm/jdk1.5.0_22/bin/java [...] -application org.eclipse.buckminster.cmdline.headless -data /pfad/zum/workspace 
INFO:  import '-C' '--template' '/pfad/zum/template_workspace' '/pfad/zur/cquery'
Workspace at /pfad/zum/workspace is not empty
Finished: FAILURE

Der Workspace ist also angeblich nicht leer. Ich frage mich warum. Den habe ich vorher per Hand gelöscht. Zur Sicherheit habe ich in einem shell-Kommando direkt vor dem Buckminster-Import nochmal per "ls" den workspace-Pfad ausgeben lassen, und der ist nicht da ("No such file or directory").

Warum gibt Buckminster in Hudson einen Fehler aus?
Benutze ich das import mit dem Template-Workspace so richtig?

 

[Wildcard]

Was genau hast du denn im Hudson Job als Kommando eingetragen?
Dort sollte nur stehen

import --template /pfad/zum/template_workspace /pfad/zur/cquery

, also nicht -data usw.

 

[tfa]

Klar, im Hudson stand kein -data. Da gibt es für den WS ja ein extra Eingabefeld.
Ich habe es jetzt anders gelöst. Die nötigen prefs-Dateien werden aus dem Template-WS einfach
"per Hand" in den Arbeitsworkspace kopiert. Das funktioniert jetzt.

 

[Wildcard]

Falls du irgendwann mal Zeit und Muse hast wäre es schon interessant was genau das Problem ist.
Wenn sich dabei rausstellt das es kein Konfigurationsfehler sondern ein echter Bug ist, dann würde ich einen Bug Report sehr begrüßen 🙂
Wahlweise für das Plugin: System Dashboard - Hudson JIRA
Oder Buckminster: https://bugs.eclipse.org/bugs/
Je nachdem wo du das Problem vermutest.

Danke

PS: So als Tipp für die Zukunft: es macht absolut Sinn möglichst viele Einstellungen direkt in den Project Specific Settings zu verankern. Damit garantierst du das jeder im Team die gleichen Warnings sieht, die gleichen Cleanup on Save actions ausgeführt werden, das gleiche Formatting durchgeführt wird, usw.

 

[tfa]

PS: So als Tipp für die Zukunft: es macht absolut Sinn möglichst viele Einstellungen direkt in den Project Specific Settings zu verankern. Damit garantierst du das jeder im Team die gleichen Warnings sieht, die gleichen Cleanup on Save actions ausgeführt werden, das gleiche Formatting durchgeführt wird, usw.

Danke, danke - aber keine Bange! Wir haben im Projekt eine eigene Eclipse-Distribution, die jeder Entwickler benutzt. Hier sind alle benötigten Einstellungen, Plug-ins, Update-Sites, SVN-Repositorys usw. vorinstalliert und konfiguriert. Die Settings selbstverständlich auch. Sollte es hier Änderungen geben (zwar selten, aber doch möglich), werden die per XML-Datei verteilt. Das funktioniert gut.
Projektspezifisch wollen wir das nicht machen, da wir in unserem Projekt über 60 Eclipse-"Projekte" (Plugins und Features) haben. Die alle einzeln zu pflegen könnte aufwendig werden.

Das Problem mit dem Template-Workspace werd ich mir nochmal anschauen.
EDIT: Ich hab dir einen Bug geschickt: [#HUDSON-8083] Importing workspace with "--template"-option fails - Hudson JIRA

 

[Wildcard]

Danke, danke - aber keine Bange! Wir haben im Projekt eine eigene Eclipse-Distribution, die jeder Entwickler benutzt.

Alles klar, so geht's natürlich auch 🙂
Danke für das anlegen des Issues. Ich schreibe in JIRA sobald ich mehr weiß.