Zmiany w jPalio i jDesignerze

Nowości

Konwencja nadawania numeru wersji

Konwencja została lekko zmodyfikowana, aby odpowiadać konwencji Maven, rozpowszechnionej w javowym świecie.
W skrócie, numer wersji jest zapisany według schematu X.Y.Z-SUFFIX
X - major version, numer zmieniany gdy, zmiany w publicznie dostępnych interfejsach wprowadzają brak kompatybilności wstecznej
Y - minor version, numer zmieniamy gdy, zmiany w publicznie dostępnych interfejsach nie wpływają na kompatybliność wstecz
Z - incremental version, numer zmieniamy w przypadku poprawek błędów i drobniejszych usprawnień
SUFFIX - opcjonalny

Aplikacja nad którą trwają jeszcze prace będzie miało wersję z końcówką -SNAPSHOT, np. 7.4.96-SNAPSHOT. Gdy prace zostanę ukończone, wersja zostanie zmieniona na 7.4.96. Na razie rezygnujemy z innych przyrostków.
Korzystanie z wersji SNAPSHOT powoduje, że artefakty z takim numerem trafiają do oddzielnego repozytorium. Wersje te nie koniecznie muszą być sprawne, dlatego też należy je odseparować od tych sprawnych. Repozytorium nadaje wersjom SNAPSHOT dodatkowy numer zbudowany na podstawie daty, kiedy artefakt trafił do repozytorium.
W Manifeście jPalio i jDesignera wersja SNAPSHOT, np. 7.4.96-SNAPSHOT, będzie zapisana w postaci:

Implementation-Version: 7.4.96-SNAPSHOT
Specification-Version: 7.4.96

Konfiguracja Gradle

Do poprawnego działania skryptów budowania jPalio, należy ustawić pewne zmienne z danymi logowania do repozytoriów oraz danymi keystore.
Zmienne te najlpiej ustawić w pliku gradle.properties umieszczonym w katalogu domowym gradle czyli ~/.gradle/gradle.properties
Przykładowe zawartość pliku:

tornRepositoryUserName=tdybowski #login do repozytorium nexus
tornRepositoryPassword=hasło #hasło do repozytorium nexus
keystoreLocation=C:\\Praca\\kod jpalio\\signed_keystore #lokalizacja keysotre
keystorepass=abc #hasło keystore
keystoretype=jks #typ keystore
signAlias=a5b0c30f-2d08 #alias podpisu

Powyższe zmienne będą współdzielone przez wszystkie skrypty gradle.

Aby wydać nową wersję jPalio oraz jDesignera należy:

  1. Uzupełnić plik changelog.md znajdujący się w głównym repozytorium projektu. Plik jest w formacie Markdown, który jest prostym zapisem tekstu wraz z formatowaniem. Użyta implementacja to markdown4j. Opis składni można znaleźć tutaj Daring Fireball: Markdown Syntax Documentation. Plik changelog zawiera historię wszystkich wersji. Dodając nową wersję należy trzymać się konwencji, że nowa wersji zostaje dopisana na górze dokumentu jako nagłówek pierwszego poziomu, czyli dla wersji 7.4.94 wygląda to tak:
    7.4.94
======
    Następnie każda kolejna zmiana jest elementem listy punktowanej, czyli powinna zaczynać się od znaku *. Na przykład:
    7.4.94
======

* New module abc

* New method in module abc
  2. W pliku gradle.properites zmienić właściwość version oznaczającą numer wersji. Nie trzeba edytować manifestu, jest on automatycznie tworzony w procesie budowania.
  3. Następnie należy uruchomić za pomocą Gradle następujące zadania:
    • jPalio:
      • uploadJpalio
      • uploadJpalioWar
      • uploadModules
      • uploadModuleDoc
      • uploadPalioServices
      • uploadChangelog
    • jDesigner:
      • uploadArchives
      • uploadSignedLibs
      • uploadAllInZip
      • uploadWebstartJnlp
      • uploadChangelog
  4. Wykonanie zadań z poprzedniego punktu powoduje umieszczenie w naszym repozytorium plików jar, war, zip powstałych w procesie budowania. Repozytorium jest na bieżąco monitorowane i jeśli tylko pojawi się nowa wersja, informacje o niej są umieszczane na nowej stronie jDesignera oraz wysyłany jest mail na alias torn-all z informacją o nowej wersji. Najważniejszym artefaktem z punktu widzenia tego procesu jest odpowiednio wypełniony changelog. Gdy plik ten jest źle wypełniony lub nie ma go w repozytorium, informacje o nowej wersji nie zostaną pokazane na stronie oraz nie zostanie wysłany e-mail. Nieukończnie wydawania spowoduje też, że nie będą działały linki do jDesignera z poziomu strony html.info.

Planowane

Rozważane