Closed eidottermihi closed 6 years ago
Hab den Vorschlag von @rowe42 kopiert:
Vorschlag: Verwenden wir doch das Maven-Filtering. Siehe hier: https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html Bei Spring-Boot-Projects etwas abgewandelt: https://stackoverflow.com/questions/36501017/maven-resource-filtering-not-working-because-of-spring-boot-dependency
Ich habe es mal kurz ausprobiert: Wenn ich eine Datei version.txt z.B. nach /src lege mit folgendem Inhalt:
Version: @project.version@ und die pom.xml so verändere:
<resources>
<resource>
<directory>build/es5-bundled</directory>
<targetPath>static</targetPath>
<filtering>true</filtering>
</resource>
</resources>
(neu ist die Zeile mit dem filtering)
dann haben wir im fertigen Build an der Stelle /src eine Datei version.txt mit folgendem Inhalt:
Version: 0.0.1-SNAPSHOT Man kann sich nun einen guten Platz überlegen, wo man das platziert. Entweder man macht einen neuen Footer-Tag in dem der Inhalt einer solchen Datei ausgegeben wird. Oder man nimmt den Platzhalter direkt in die locales.json auf und gibt sie einfach im Footer aus (dann kann man noch sehr schön sprachabhängig die Struktur verändern).
Was meint ihr? Wäre das eine valide Lösung? Wäre zumindest sehr einfach...
@ejcsid @dragonfly28
Ich denke es gibt hier zwei Dinge, die wir getrennt voneinander diskutieren sollten:
zu 1.: Ich denke die Lösung von @rowe42 ist ganz schick und mit unserem Hintergrund (das ist nunmal vor allem Maven) relativ einfach umsetzbar. Ich würde zu dieser Lösung tendieren.
zu 2.: Aktuell habe ich das Gefühl, dass wir den Build Prozess etwas stiefmütterlich behandelt haben (@rowe42 bitte korrigier mich, wenn das nicht stimmt). Das sollten wir ändern. Wir müssen einen Plan haben, was wir mit der JS Pipeline machen wollen/müssen und was mit Maven. Spontan fallen mir da die Themen ServiceWorker, Regressionstests, Linting, etc. ein. Da wäre es sehr hilfreich, wenn du dich da einbringen könntest @eidottermihi.
Stimmt, da haben wir bisher relativ wenig gemacht. Ist aber auch etwas, wo ich @ejcsid und @a52team mit im Boot sehe, da das Ganze ja auch im Jenkins lauffähig sein muss.
Für die JavaScript-Themen ist denke ich auch sinnvoll / vorgesehen, dass sich @tderflinger einbringt (fällt mir ein, weil du was von Linting schreibst; das hatte er auch schon erwähnt).
zu 1.: ebenfalls 👍 für die Lösung via Maven Filtering: Ist schnell und einfach umsetzbar.
zu 2./Linting: Habe neues Issue erstellt #259
Ok. @eidottermihi magst du einen neuen branch erstellen, einen schönen Footer basteln und da das maven Filtering aktivieren? Kannst dann gern den merge request an mich schicken...
Kann ich machen - dieses Issue müsste mir nur jemand zuweisen, selber kann/darf ich das nicht.
Anforderung:
Der aktuelle Polymer Build via
polymer build
unterstützt keine "Veränderung" der Sourcen zur Build-Zeit (siehe https://github.com/Polymer/polymer-cli/issues/408).Mein Ansatz in #252 war, den Build mittels
Gulp
und polymer-build durchzuführen. Ein Beispiel von Polymer selbst gibts hier: https://github.com/PolymerElements/generator-polymer-init-custom-build Mit Gulp ist es dann relativ einfach, Parameter oder Environment Variablen in die Source zu injizieren.Damit wäre z.B. auch möglich, das in #189 angedachte Feature zur Setzen der Backend-URL "von außen" umzusetzen.
Zu klären ist:
Da
polymer build
intern auch lediglich diepolymer-build
Library benutzt, denke ich, dass es möglich sein sollte, den gleichen Build-Output zu erzeugen. Ich würde das die kommenden Tage noch weiter ausprobieren.@xdoo @rowe42 Spricht denn aus eurer Sicht grundsätzlich etwas gegen die Verwendung von Gulp? Bzw. hättet ihr andere Ideen?