Newsgroup: it.comp.java
Titolo: [per esperti] deployment inusuale

Ho l'esigenza di sviluppare più applicazioni che utilizzano alcuni 
file in comune che sto sempre sviluppando io.
La struttura in fase di sviluppo è la seguente
\myapp_1
	\pack1
		\Class1MyApp_1.java
		\Class2MyApp_1.java
	\pack2
		\Class3MyApp_1.java
		\Class4MyApp_1.java
\myapp_2
	\pack1
		\Class1MyApp_1.java
		\Class2MyApp_1.java
	\pack2
		\Class3MyApp_1.java
		\Class4MyApp_1.java
\mylib
	\pack1
		\UtilClass1.java
	\pack2
		\UtilClass2.java
(le etichette sono significative. Cioè, i sottopackage pack1 delle
varie applicazioni e della libreria hanno lo stesso nome)
Le classi specifiche per ogni applicazione (per esempio le ClassMyApp
possono essere svariate
e differenti da applicazione ad applicazione).
Per motivi *STRETTAMENTE* legati al device sul quale myapp_1 e myapp_2
(e tutte le altre myapp_n) devono essere deployate, sono costretto a
mettere FISICAMENTE tutte le classi della \mylib nel package delle
applicazioni e cioè:
\myapp_i
	\pack1
		\Class1MyApp_i.class
		\Class2MyApp_i.class
		\UtilClass1.class
	\pack2
		\Class3MyApp_i.class
		\Class4MyApp_i.class
		\UtilClass2.class
e diStribuirle in questo formato (appena scritto).
Vorrei evitare di dover sviluppare con la seguente metodologia:
\myapp_i
	\pack1
		\Class1MyApp_i.java
		\Class2MyApp_i.java
		\UtilClass1.java
	\pack2
		\Class3MyApp_i.java
		\Class4MyApp_i.java
		\UtilClass2.java
perchè avrei problemi di disallineamento (le utilclasses potrei
doverle modificare durante il processo di sviluppo) nella scrittura
(quasi contemporanea e in gruppo) delle varie applicazioni.
Chi ha qualche idea di come poter portare avanti i vari progetti (se
interessa sto usando Eclipse, ma il ragionamento suppongo prescindere
da quale ambiente si utilizza)?
Cioè, come vi organizzereste voi il lavoro?
ciao e grazie.

 da quale ambiente si utilizza)?
Forse ho capito male... ma un classico script Ant ?
http://ant.apache.org/
-- 
Njc

...

mmhh...
il problema sta nella denominazione dei packages delle varie classi.
Infatti se io sviluppo la lib in un progetto avra nome
\mylib
 \pack1
  \UtilClass1.java
 \pack2
  \UtilClass2.java
ok?
Quindi il package di UtilClass1.java sarà
mylib.pack1.UtilClass1.java
Nel momento in cui devo deployarla fisicamente nell'applicazione avrò
che la classe
       myapp_1.pack1.Class1MyApp_1.java
dovrà fare riferimento a 
       myapp_1.pack1.UtilClass1.java
e non a
       mylib\pack1.UtilClass1.java
Quindi, ho nella procedura di ant avvio uno script che mi modifica il
codice e ricompila e poi ne fa il deploy con le nuove dichiarazioni di
package - nelle classi della lib - e le nuove dichiarazioni di import
- nelle classi dell'applicazione.
Questa soluzione però mi sembrava un pò strana, inusuale (come
d'altronde è inusuale la mia esigenza) e error-prone.
Quindi volevo sapere se qualcuno mi sapeva suggerire un modo di
organizzare i sorgenti (e farne un deploy) in modo tale da poter
sviluppare le lib in un singolo ambiente (altrimenti dovrei avere
delle copie fisiche da tenere allineate nelle varie applicazioni) e
poi fare un deploy che prende i class e me li spara nei package delle
applicazioni.
Ho pensato di sviluppare la lib in package
 \pack1
  \UtilClass1.java
 \pack2
  \UtilClass2.java
senza il package mylib, ma gli mancherebbe comunque il parent
dell'applicazione.
Quindi, ant sicuramente sarebbe uno strumento che dovrò integrare nel
deploy, ma l'ambiente di lavoro ancora non so bene come organizzarlo.
ciao e grazie.

 dell'applicazione.
E questo costituisce un problema ?
Vista l'entità dei vincoli che hai, questo mi sembrerebbe il minimo;
boh, io vedo solo 2 strade: questa (che reputo la no-brain choice) e quella
del refactoring automatico a colpi di espressioni regolari.
-- 
Njc

 e quella del refactoring automatico a colpi di espressioni regolari.
intendi la rinominazione dei package prima della compilazione?
ciao e grazie

 intendi la rinominazione dei package prima della compilazione?
sì.
-- 
Njc

 C'è anche un vincolo che vieta di usare zip/jar/jad ?
ora indago...ma fa differenza? Una volta caricati nel classpath...
[cut]

 ora indago...ma fa differenza? Una volta caricati nel classpath...
uhm... bella domanda... di preciso non lo so, ma è probabile che faccia
differenza... insomma se il nome del package è lo stesso, le librerie sono
in un jar e l'applicazione in un altro, credo proprio che non possa
funzionare.
Comunque io credevo che le applicazioni fossero isolate (nel deploy), o no ?
La questione dei "pacchetti" era solo per evitare marmellate tra i file di
diverse applicazioni, visto che avevo ipotizzato di usare solo 2 package
(org.zzz.pack1, org.zzz.pack2).
-- 
Njc

 (org.zzz.pack1, org.zzz.pack2).
esatto.

 esatto.
Allora è sufficiente "org.zzz", e non ci sono problemi se si evita di
specificare anche "myapp_n" nel package-name, no ?
La marmellata ci sarà solo nel build di sviluppo, mentre in deploy sarà
tutto «pulito».
-- 
Njc

dunque, ti ringrazio per la risposta ma ora non ho molto tempo per 
"studiarla".
Nessuno si è fatto avanti... non so se hanno seguito il thread.
Ti farò sapere, grazie, ciao.
