iBaffiPro ha scritto:
Ci sono parecchie cose da sistemare ma credo prima di tutto il pom.xml.
Mi ha già preceduto
migliorabile con ottimi consigli ma aggiungo comunque anche io un po' di cose perché nel tuo pom.xml ci sono svariate cose sbagliate, discutibili o semplicemente inutili. Cioè ... stai facendo un po' di pasticci ....
iBaffiPro ha scritto:
Ogni volta che faccio un aggiornamento alla WebApp creo un nuovo progetto e questo per evitare di arrivare ad un punto di non ritorno.
Ci sono approcci 100 volte migliori, ad esempio usare un sistema di versionamento come Git. La cosa bella di Git è che puoi fare quasi tutto in "locale", anche senza un server di riferimento! Puoi fare i commit, branch, merge, discard delle modifiche ecc... tutto "offline". Poi chiaramente se hai il progetto su es. GitHub o Bitbucket, allora per push/pull ovviamente devi essere online e avere i riferimenti del repo remoto.
Questo a differenza di altri sistemi come SVN che sono invece server "centrici", ovvero per qualunque cosa (anche un banale create branch) devi essere online e connesso al server altrimenti non fai un tubo ...
iBaffiPro ha scritto:
Nel frattempo, ho anche deciso di creare un’applicazione con i moduli possibilmente più recenti possibili e questo sia per adeguarmi ai nuovi standard sia per evitare di ritrovarmi con un’applicazione che in futuro debba essere aggiornata.
Vedi quanto ti ha detto
migliorabile. Non cercare di rincorrere sempre/solo l'ultimissima versione della tal libreria/framework X. La scelta delle versioni va fatta in maniera ragionata!
iBaffiPro ha scritto:
1) Se lancio l’applicazione la WebApp parte senza problemi ma se poi digito nel terminale mvn clean install questa smette di funzionare e per farla ripartire devo cancellare la cartella target e farla ricreare all’IDE. Inoltre, il comando mvn clean install fornisce degli errori. Potrei aver sbagliato ad impostare qualche variabile d’ambiente? Perché accade questo?
Il problema-errore è come hai specificato la versione di Java.
Allora: innanzitutto la property <java.version> è una cosa
specifica di Spring Boot. Nei progetti Maven più tradizionali si usano di norma <maven.compiler.source> e <maven.compiler.target> .
Perché in Spring Boot è diverso? Semplicemente perché Spring Boot "fattorizza" la gestione della versione più a monte. Il tuo pom ha un parente,
spring-boot-starter-parent, se guardassi il pom di questo vedresti:
<maven.compiler.source>${java.version}</maven.compiler.source>
<maven.compiler.target>${java.version}</maven.compiler.target>
Quindi è semplicemente un livello di indirezione di più e basta. Non solo: lì nel spring-boot-starter-parent ci sono GIÀ le property per il encoding (fisso a UTF-8), quindi nel tuo pom
non servirebbe metterle.
Comunque: tu hai messo <java.version>1.16.0.1</java.version>
Questo è sbagliato!! Il source/target level in generale indica solo la versione di Java,
NON la build di un JDK.
Se usi Java 8 ---> <java.version>
1.8</java.version> (oppure <java.version>
8</java.version> )
Se usi Java 11 ---> <java.version>
11</java.version>
Se usi Java 16 ---> <java.version>
16</java.version>
NON ha importanza se il JDK è un 1.8.0 build 281 o 291 o un 11.0.11 o un 16.0.1 .
iBaffiPro ha scritto:
2) Nel file pom.xml c’è la dipendenza commons-validator a cui devo dare assolutamente il numero della versione altrimenti quando faccio il processo che ho descritto sopra (copio src, pom.xml, avvio…) l’IDE non riesce a compilare l’applicazione, non parte e fornisce degli errori. A me non convince molto questo modulo e vorrei sapere se esiste qualcosa di meglio per fare una semplice convalida di un form.
La Apache Commons Validator contiene solo una serie di classi e metodi di utilità che possono essere utili per validazioni particolari.
Ma in ambito Spring Framework/Boot per la validazione si usa di norma la Java Validation API, di cui la Hibernate Validator è la implementazione standard.
Ovvero, a livello pratico, si tratta di usare le varie annotation tipo @NotNull, @NotEmpty, @Size, @Min, ecc....
Con Spring Boot è sufficiente avere il
spring-boot-starter-validation (che hai!).
iBaffiPro ha scritto:
Vorrei qualcosa di semplice ma di avvalorato, semplice e possibilmente intramontabile.
Nello sviluppo di software, non c'è niente di "intramontabile" ....
iBaffiPro ha scritto:
3) Altra cosa che vi chiedo è se con questa nuova politica (prendo l’ultima JDK, l’ultima versione di Maven, l’ultima versione di Spring Boot, ecc…) potrei arrivare ad un punto in cui essere costretto a dover fare marcia indietro per qualche dipendenza ancora non disponibile con i nuovi strumenti di java.
Come già detto, non cercare di rincorrere solo l'ultimissima versione!
iBaffiPro ha scritto:
4) Altra cosa che con capisco è se scrivere <artifactId>script</artifactId> è corretto oppure no dato che io cambio continuamente nome alla cartella del progetto. E’ giusto scrivere il tag sopra oppure dentro l’artifact devo mettere il nome della cartella che contiene la cartella src ed il file pom.xml?
Allora: il nome del progetto nel IDE e il artifactId tecnicamente possono anche differire, non è quello il problema.
Il artifactId però dovrebbe avere un nome sensato ... non "script".
Il groupId invece serve a raggruppare più artifact, tipicamente per rappresentare una azienda, un contesto o comunque un insieme di artifact correlati tra di loro.
Io ad esempio sui miei progettini personali più recenti metto <groupId>it.andbin</groupId> perché? ... perché sono proprietario di andbin.it quindi nessun'altro può (lecitamente) dichiarare quel groupId.
iBaffiPro ha scritto:
5) Le varie dipendenze, jdk, plugin, framework, ecc… in fase di pubblicazione possono essere le ultimissime oppure sarebbe meglio che l’ultima cifra fosse pari? C’è qualche criterio da tenere sotto controllo?
Non tutte le librerie/framework adottano uno schema di versionamento in cui i numeri "pari" indicano versioni
stabili e quelli dispari no (lo fa o faceva il kernel di Linux).
Per le librerie Java è più tipico usare il
Semantic Versioning
iBaffiPro ha scritto:
<version.postgresql>11.4</version.postgresql>
Questo non va bene, a parte il fatto che non lo stai usando concretamente.
Il punto è che Spring Boot ha una opinione sulla versione di moltissime librerie a cui fa riferimento. Queste "opinioni" sono nel artifact spring-boot-dependencies (che è il parente di spring-boot-starter-parent).
Nel spring-boot-dependencies si vede es.:
<postgresql.version>42.2.19</postgresql.version>
Questa è la versione che tirerebbe dentro se dichiari la dependency del driver SENZA mettere la versione.
E nota: è la versione del driver, NON del server PostgreSQL !!
<dependency>
<groupId>org.postgresql</groupId>
<artifactId>postgresql</artifactId>
<scope>runtime</scope>
</dependency>
Se vuoi ridefinire la versione, NON devi mettere <version> nel <dependency> ma devi ridefinire la property con lo stesso nome che usa Spring Boot, ovvero
<postgresql.version>
iBaffiPro ha scritto:
<java.version>1.16.0.1</java.version>
Già spiegato prima.
iBaffiPro ha scritto:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<source>1.16.0.1</source>
<target>1.16.0.1</target>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
Anche questo non ti serve se vai solo ad impostare quelle 3 configuration che sono GIÀ gestite da Spring Boot. Discorso diverso se dovessi impostare altro di molto più particolare nel <configuration> es. il <failOnWarning> o il <verbose> .
iBaffiPro ha scritto:
<repositories>
<repository>
<id>spring-milestones</id>
<name>Spring Milestones</name>
<url>https://repo.spring.io/milestone</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<repository>
<id>spring-snapshots</id>
<name>Spring Snapshots</name>
<url>https://repo.spring.io/snapshot</url>
<releases>
<enabled>false</enabled>
</releases>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>spring-milestones</id>
<name>Spring Milestones</name>
<url>https://repo.spring.io/milestone</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
<pluginRepository>
<id>spring-snapshots</id>
<name>Spring Snapshots</name>
<url>https://repo.spring.io/snapshot</url>
<releases>
<enabled>false</enabled>
</releases>
</pluginRepository>
</pluginRepositories>
Ecco, chiariamo un attimo la questione delle snapshot/milestone.
Per tutti i prodotti della famiglia Spring vengono rilasciate le release ufficiali e anche delle "snapshot" (istantanee in un certo momento) e le "milestone" (pietre miliari nello sviluppo di una certa nuova versione).
Le release sono sui repo specifici di Spring ma ANCHE sul Maven Central ufficiale. Quindi non c'è bisogno di quei repository specifici.
Le snapshot/milestone invece si trovano SOLO sui repo di Spring. Se tu vuoi qualcosa di perlomeno stabile e valido, allora DIMENTICA le snapshot/milestone!!