Anzeige von Mavens project.version im Frontend

[eidottermihi]

Anforderung:

Als Tester möchte ich auf der Oberfläche der Anwendung erkennen, in welcher Version die Anwendung gerade vorliegt/deployed ist.

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:

• Erzeugen wir immer den Polymer-CLI "es5-bundled" Output?

Da polymer build intern auch lediglich die polymer-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?

[xdoo]

#254 Ist das selbe.

[xdoo]

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

[xdoo]

Ich denke es gibt hier zwei Dinge, die wir getrennt voneinander diskutieren sollten:

1. Wie bekomme ich Projektinformationen in den Footer?
2. Wie schaut der Buildprozess des Frontend Projektes aus?

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.

[rowe42]

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.

[rowe42]

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).

[eidottermihi]

zu 1.: ebenfalls 👍 für die Lösung via Maven Filtering: Ist schnell und einfach umsetzbar.

zu 2./Linting: Habe neues Issue erstellt #259

[rowe42]

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...

[eidottermihi]

Kann ich machen - dieses Issue müsste mir nur jemand zuweisen, selber kann/darf ich das nicht.