Eclipse: sostituisce il percorso della libreria definito in project.properties

Question

Sto utilizzando ActionBarSherlock come libreria. Non abbiamo incluso l'ABS nel nostro repository, quindi tutti coloro che partecipano allo our project devono scaricarlo e installarlo separatamente. ActioBarSherlock è un progetto di libreria Android e l'ho eseguito aprendolo e il mio progetto nello stesso spazio di lavoro di Eclipse (nessuno dei due viene copiato nello spazio di lavoro, entrambi esistono in un'altra cartella) e aggiungendolo nel mio project.properties seguendo questo: Referencing a library project.

Quel percorso di riferimento è relativo e poiché ognuno potrebbe avere ABS in una cartella diversa, abbiamo anche percorsi diversi nel file di Eclipse come android.library.reference.1. Esiste un modo per sovrascrivere localmente quel percorso della libreria in modo che possiamo avere project.properties nel nostro repository ma Eclipse userà localmente qualche altro percorso? Attualmente devo correggere manualmente quel percorso dopo ogni volta che estraggo dal nostro repository a causa di percorsi diversi.

Esiste other *.properties files ma Eclipse li ignora:

local.properties

personalizzabili proprietà specifiche del computer per il sistema di compilazione. Se si utilizza Ant per creare il progetto, questo contiene il percorso dell'installazione di SDK. Poiché il contenuto del file è specifico per l'installazione locale dell'SDK, le proprietà local.properties non devono essere mantenute in un sistema di controllo di revisione dell'origine. Se si utilizza Eclipse, questo file non viene utilizzato.

ant.properties

proprietà personalizzabili per il sistema di generazione. È possibile modificare questo file per sovrascrivere le impostazioni di build predefinite utilizzate da Ant e fornire anche la posizione del keystore e dell'alias chiave in modo che gli strumenti di compilazione possano firmare l'applicazione quando si crea in modalità di rilascio. Questo file è parte integrante del progetto, quindi conservalo in un sistema di controllo di revisione del codice sorgente. Se si utilizza Eclipse, questo file non viene utilizzato.

Answer 1

Basta che ogni persona lo abbia inserito in projectroot/libs. Le versioni più recenti (ADT 17 e successive, IIRC) dell'ADT la raccoglieranno automaticamente e la compileranno nella tua app. Si noti che la cartella è libs, con un s e non lib. L'utilizzo di /lib non funzionerà.

Answer 2

Opzioni:

• project.properties: Si potrebbe creare un collegamento in ogni cartella home degli utenti, libs e hanno il percorso nella project.properties riferiscono a ~/libs

• Utilizzo di un comune libreria: Creare un progetto di libreria chiamato "comune". Nelle impostazioni, fai esportare il barattolo. Nella tua applicazione Android, importa il barattolo.

Personalmente penso che la configurazione con Maven sarebbe la cosa migliore ma la seconda opzione era la più veloce.

Answer 3

Che dire se si ignorano i project.properties nel repository? In questo modo ogni utente può mantenerlo e non sarà necessario sostituirlo continuamente. Non penso che tu possa ignorarlo localmente.

Un'altra opzione per semplificare le cose è che è possibile esportare il progetto come file JAR invece di farne riferimento come progetto di libreria. Se non è necessario modificare il codice ABS, è possibile fare clic con il tasto destro del mouse sul progetto -> java -> jar file e tutti gli sviluppatori possono tenerlo nello stesso posto per semplicità.

Answer 4

Modifica: questa domanda non è più necessaria per il nostro progetto da quando ci siamo trasferiti da Eclipse al sistema di sviluppo Android Studio e Gradle. Anche Eclipse con Maven avrebbe dovuto funzionare, come suggerito da @bgs.

Il nostro approccio precedente:

Ancora alla ricerca di una migliore alternativa, ma finora abbiamo finito per tenere project.properties nella nostra repo. project.properties non viene sovrascritto se non ci sono modifiche ad esso durante la trazione. Suggeriamo anche nel nostro README che agli utenti di aggiungere questo

[alias] 
commit = commit -X project.properties 

alla loro file di configurazione .hg/hgrc per evitare che accidentalmente che impegnano i cambiamenti di tale file.

Questo metodo ha almeno uno svantaggio: quando si uniscono, è possibile che si verifichi un errore come questo abort: cannot partially commit a merge (do not specify files or patterns) anche quando si esegue l'unione con hg commit -m 'merge'. Se ciò accade, disabilita temporaneamente l'alias.