A: Se è la prima volta che si installano gli mddtools sulla postazione e per un determinato utente, oppure se era in precedenza presente una versione di tool precedente alla 1.5.0 (guigen), 1.1.0 (servicegen), allora è necessario configurare le informazioni identificative dell'utilizzatore, che sono utilizzate dal meccanismo di usage tracking. Per i dettagli sul meccanismo e per le modalità di configurazione è disponibile un'apposita sezione.

A: Il frammento non trovato è di fatto la "cartuccia" di generazione configurata nel file .oaw. Affinchè il sistema di generazione riesca a lanciare questa cartuccia è necessario che il progetto generatore abbia tra le proprie dipendenze i plugin dello strumenti geenratore desiderato (guigen|servicegen|datagen).

Per risolvere il problema è sufficiente aggiungere le dipendenze dall'apposito editor.

A: Non è possibile inserire codice custo al di fuori delle apposite regioni protette, pena la perdita del codice a fronte di una successiva rigenerazione.

Non è altresì possibile inserire regioni protette aggiuntive.

Occorre pertanto esaminare il caso specifico (e l'esigenza specifica), sottoponendo il problema al gruppo di sviluppo del tool:

• se l'esigenza ha un carattere di generalità è possibile che la nuova regione protetta sia effettivamente aggiunta in una verisone successiva del tool
• se l'esigenza non ha un carattere di generalità verrà suggerita una soluzione alternativa.

A: I generatori di mddtools non cancellano mai nessun file, pertanto ogni file/classe aggiuntiva sarà mantenuta nelle rigenerazioni successive.

A: Si, è corretto. Occorre rimuovere manualmente le classi obsolete dal progetto.

A: l'identificativo delle regioni protette è ottenuto calcolando l'hash-code di una stringa che identifica univocamente tale regione protetta e non può essere perciò modificato a piacimento. Tale stringa è tipicamente ottenuta concatenando varie componenti testuali. Il dettaglio delle componenti costitutive è un internal del generatore. Il motivo per cui si calcola l'hash-code invece che utilizzare il codice testuale sta nell'evitare che il commento che delimita la regione protetta vada a capo a fronte di formattazioni automatiche del codice generato, rendendo in questo modo impossibile per il generatore individuare le regioni protette (la lunghezza dell'hash-code è invece per definizione fissa).

A: Occorre innanzitutto verificare nei dettagli dell'errore qual'è il path dei due file che presentano lo stesso ID di regione protetta:

• se i due file sono distinti come path ma identici come nome (è il caso più comune), allora si tratta probabilmente di un problema di configurazione del progetto generato nel workspace eclipse: tipicamente il processo di build automatico dell'IDE sposta nella directory target eventuali file di configurazione (es. xml). In questo caso all'atto della rigenerazione il modulo che gestisce le regioni protette troverebbe uno stesso ID di regione protetta in due file differenti, con conseguente errore. Per questa ragione il processo di generazione come prima operazione cancella le directory standard di build e di file temporanei. Se in eclipse, però la directory di build non è impostata con il valore standard CSI (build/classes) ma con, ad esempio, il valore standard per i progetti eclipse (bin) il processo di pulizia prelimiare non riuscirebbe a prevenire le regioni duplicate. La soluzione sta semplicemente nel configurare il percorso di build in modo che valga build/classes.
• se gli id duplicati sono segnalati sullo stesso file, allora potrebbe esserci un problema di modellazione o, in casi più rari, un bug nel generatore. Tipicamente per capire se siamo nel primo o nel secondo caso è indicativo analizzare il codice nel punto in cui è segnalato l'errore e verificare se, oltre all'ID vi sono altri elementi duplicati in modo illegale (es. il nome del metodo java all'interno del quale vi è l'ID che ha generato l'errore.

A: No, è sufficiente inserire gli statement di import nell'apposita regione protetta e non lasciarli inserire all'IDE con le funzioni di organizzazione dell'import (che rispettano questo vincolo solo casualmente).

A: No, non è consigliato. L'aggiornamento ad una nuova versione di generatore solitamente non è fonte di problemi, in quanto vengono gestite la retrocompatibilità funzionale e, parzialmente, di codice generato. E' però consigliabile eseguire in modo cosciente la migrazione ad una nuova versione, tenendo presente che:

• se la nuova versione fornisce una correzione o una nuova funzione che risultano di immediata utilità per il progetto, l'opportunità di migrare è superiore
• se le correzioni o le nuove funzioni fornite dalla nuova versione non sono di immediata utilità per il progetto l'upgrade può essere rimandato.

A: Gli accorgimenti consigliati per il passaggio ad una nuova versione di plugin sono i seguenti:

• effettuare l'operazione solo dopo aver storicizzato su SVN una versione stabile generata con la versione precedente di plugin
• come prima operazione dopo l'upgrade effettuare una rigenerazione del progetto senza modificare il modello (a meno che non sia richiesto nelle note di release).
• dopo la prima rigenerazione verificare:
  • se il progetto rigenerato continua a compilare correttamente
  • quali variazioni ci sono sul codice generato rispetto alla versione consolidata
• E' opportuno pianificare una fase di test di non regressione sull'applicazione rigenerata. come criterio empirico, il livello di approfondimento del test dovrebbe aumentare tanto quanto più numerose sono le variazioni rilevate sul codice generato.

A: La versione di generatore che ha generato un progetto è evidenziata in alcuni file generati con una scritta del tipo:

Generato da GUIGEN, versione 1.5.0.021

La collocazione di quest ainformazione dipende dal plugin:

• nel caso di guigen l'informazione è contenuta nel file build.properties
• nel caso di servicegen l'informazione è contenuta nel file build.properties
• nel caso di datagen l'informazione è contenuta nel file dao-beans.xml