Come spostarsi dai percorsi hardcoded nei nostri processi di compilazione

Question

Come spostarsi dai percorsi hardcoded nei nostri processi di compilazione

#1 da (2 voti)

0

Abbiamo una serie di strumenti Java che vengono creati ed eseguiti localmente. Ogni volta che uno degli sviluppatori commette un cambiamento, tutti gli altri (inclusi i non sviluppatori) devono eseguire un aggiornamento e creare gli strumenti.

Tutti usano macchine Windows, quindi chiunque abbia progettato i processi di costruzione ha deciso di posizionare tutto in una cartella chiamata C:\build e scaricare tutti i file di classe nelle cartelle appropriate. Ad esempio, la cartella potrebbe apparire come

C:\build\firstTool\
C:\build\secondTool\
C:\build\settings.ini

Abbiamo anche un'enorme cartella di librerie dove vanno tutti i barattoli, ed è posizionata qui

C:\lib\

Di conseguenza, molte classi assumono semplicemente che questo è il luogo in cui i file verranno archiviati e avranno percorsi codificati in tutto il mondo.

Che cosa posso fare per pulire le cose? Non voglio che gli utenti debbano creare strumenti, né voglio che debbano aggiornare i repository verificati alla fine.

Personalmente, penso che gli sviluppatori dovrebbero essere quelli che mantengono le versioni.

java

posta That Umbrella Guy 04.03.2014 - 19:33

fonte

1 risposta

Leggi altre domande sui tag java

Questa è una variante del modello del modulo? Qual è la differenza tra un albero di scherma e un albero di ricerca binaria ottimale?

score 2 · Answer 1

Percorsi relativi

potresti definire alcune variabili d'ambiente in Windows. Per gli utenti Linux, questo dovrebbe essere familiare.

C:\> SET VARIABLE_NAME="path\to\dir"

imposta la variabile di ambiente VARIABLE_NAME su quel percorso. Windows sostituirà quindi %VARIABLE_NAME% con qualsiasi cosa tu inserisca tra virgolette, indipendentemente dal fatto che sia valida o meno. (Se non lo è, genererà un errore.) Ad esempio, puoi elencare il contenuto del percorso usando dir come segue:

C:\> dir %VARIABLE_NAME%

Potresti creare un file .bat che imposterà queste variabili d'ambiente e quindi chiamerà lo script di compilazione appropriato. Le variabili di ambiente sono valide solo per la vita dello script che le chiama.

Ma non è proprio quello che dovrebbe fare. Dovresti usare uno strumento di compilazione.

Strumenti di creazione

Gli strumenti di costruzione ti permetteranno di avere un maggiore controllo sulle build, gestire le dipendenze e i cicli di vita del progetto. Dovresti prendere in considerazione di passare a uno per cercare di alleviare alcuni dei dolori legati alla costruzione che stai provando ora. Attualmente ci sono 3 grandi nomi nella comunità di build. Ho incluso collegamenti alle pagine del progetto, con una breve descrizione di seguito.

Maven

Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information

Ant

Apache Ant is a Java library and command-line tool whose mission is to drive processes described in build files as targets and extension points dependent upon each other. The main known usage of Ant is the build of Java applications. Ant supplies a number of built-in tasks allowing to compile, assemble, test and run Java applications. Ant can also be used effectively to build non Java applications, for instance C or C++ applications. More generally, Ant can be used to pilot any type of process which can be described in terms of targets and tasks.

Gradle

Gradle is build automation evolved. Gradle can automate the building, testing, publishing, deployment and more of software packages or other types of projects such as generated static websites, generated documentation or indeed anything else.