Potrebbe Free Pascal vantaggio di qualcosa come Apache Maven?

Question

Apache Maven è molto popolare costruire e di dipendenza strumento di gestione in Java open source ecosfera.Ho fatto alcuni test per scoprire se è in grado di gestire compilato Free Pascal / Delphi unità e l'ho trovato facile da implementare.Così sarebbe possibile

• versione open source librerie precompilate per il Free Pascal (o Delphi) in un pubblico repository Maven
• includere i metadati in questo repository che contiene informazioni di dipendenza
• usare Maven sulla riga di comando per scaricare la libreria open source dal repository pubblico, e risolvere automaticamente le dipendenze
• locale repository, lavorando come proxy, potrebbe essere usata per la cache utilizzati di frequente i binari
• automatic checksum di generazione e di verifica (fornito da Maven) consentirebbe di ridurre il rischio di scaricare danneggiato i binari
• il codice sorgente, e anche i file di documentazione potrebbe essere fornito con i file binari
• i binari possono essere forniti con o senza informazioni di debug
• continuous integration server come Hudson, TeamCity o CruiseControl può essere utilizzato per costruire progetti ogni volta che le modifiche sono state presentate per l'origine del sistema di controllo e notifica agli sviluppatori di costruire errori

Questo modo di gestione delle dipendenze può essere molto utile per i progetti open source che utilizza molte librerie di terze parti con le dipendenze complesse.Non per evitare i conflitti tipici causati dall'utilizzo di versioni errate.

Per lo sviluppatore, il flusso di lavoro per la modifica e la costruzione di un progetto dovrebbe essere ridotto al minimo:

• checkout del progetto di origine interna e sistema di controllo di versione
• modificare il file di origine(s)
• eseguire mvn package per scaricare automaticamente tutte le richieste di librerie di terze parti (precompilato unità) se non ancora nella workstation locale del repository
• compilare ed eseguire

L'unico file di Apache Maven che è richiesto nella cartella del progetto è la POM.XML file contenente le informazioni del progetto.

Edit:mentre Maven è utilizzabile per alcuni dei compiti richiesti, l'implementazione di una soluzione come Maven in nativo Free Pascal avrebbe alcuni vantaggi:no Java SDK richiesto, il supporto per tutte le piattaforme di sviluppo dove il Free Pascal è disponibile, la manutenzione e lo sviluppo del plugin in Pascal.

Utilizzo di Maven-come strumento potrebbe non essere utile per i progetti open source solo - progetti commerciali potevano accedere e utilizzare i manufatti pubblici repository Maven nello stesso modo.

Maven caratteristiche sono elencate in http://maven.apache.org/maven-features.html

---

Aggiornamento:

un esempio di utilizzo potrebbe essere la generazione di Lazzaro, dove Maven scaricare tutte le librerie richieste e richiamare il compilatore con il necessario costruire percorso di argomenti.Cambiamenti nelle dipendenze su livelli inferiori sarebbero propagate automaticamente verso il genitore costruire.

Possibili benefici:

• meno tempo necessario per impostare un nuovo lavoro stazione, nessun manuale di installazione di librerie di terze parti richieste
• meno errori causati da un errato biblioteca versioni, il rilevamento di versione conflitti (per esempio, se due librerie dipendono da diversi versioni di un terzo biblioteca)
• i manufatti che vengono creati inhouse può essere aggiunto locale maven repository e condiviso tra gli sviluppatori e di progetto, centrale conservazione di tutti i manufatti con metadati
• versioni sono riproducibili solo utilizzando la stessa fonte e il progetto file di metadati (pom.xml)
• può ridurre il tempo di sviluppo e progetto di aumento di stabilità

Update #2:FPMake

il FPMake sistema di generazione di Free Pascal sembra essere uno strumento con molte potenzialità, in molti dettagli, è molto simile alla Maven:

• FPMake è un pascal costruzione a base di sistema, sviluppato e distribuito con FPC
• FPMake standardizza l'edificio, definendo alcuni limiti, come standard directory
• il comando fppkg <packagename> si cerca in un database per il pacchetto, estrarre, e quindi compilare fpmake.pp e l'esecuzione
• ha standard di costruire obiettivi (pulire, costruire, installare, ...)
• è possibile creare un 'manifesto' file adatto per l'importazione in un repository (come mvn deploy o mvn install), il manifesto è un file XML che sembra molto simile a un pom.xml Maven:

FPMake file manifest:

      <packages>
        <package name="my-package">
          <version major="0" minor="7" micro="6" build="1"/>
          <filename>my-package-0.7.6-1.zip</filename>
          <author>my name</author>
          <license>GPL</license>
          <homepageurl>http://www.freepascal.org/</homepageurl>
          <email>myname@freepascal.org</email>
          <description>this is the package description</description>
          <dependencies>
            <dependency>
              <package packagename="rtl"/>
            </dependency>
          </dependencies>
        </package>    
      </packages>

Answer 1

Freepascal ha lavorato su un pacchetto il proprio sistema, in un incrocio tra apt-get e freebsd stile.(scarica il sorgente/build/installare automaticamente), chiamato fppkg.Tuttavia il lavoro è in fase di stallo.Persone che investono tempo, sono il collo di bottiglia, non le persone che vogliono scegliere strumenti.

Per quanto Maven va, non mi piace ausiliaria strumenti che necessitano di installazione di enormi esterno runtime.Potrebbe essere un bene per un grosso app (come Open Office), ma non per un util.

Anche io preferisco uno strumento che è stato progettato per la FPC realtà e il flusso di lavoro.Strumenti di documentazione, strumenti di generazione, sistemi di download, testsuite sistemi sono già tutti lì, è solo bisogno di una persona che dedica un sacco di tempo per farlo accadere.

Alcuni tipici problemi quando si introduce una nuova tecnologia in un progetto come FPC, e perché si ha la tendenza a rendere i propri strumenti:

• necessità di formare 20+ committer in part-time.
• Il solo COMUNE linguaggio di programmazione che si può assumere è Free Pascal.Anche Delphi funzionamento interno non può essere dato per scontato di essere conosciuta (molti committer è venuto direttamente a FPC o ancora tramite TP o un Mac Pascal)
  • Ovviamente che fa qualcosa con i plugin in una lingua diversa fastidioso.
• Script Bash è un secondo vicino.(g)fare il terzo, ma già un ordine di grandezza in meno.
• Tutti i server *nix-like (FreeBSD, OS X, Linux), ma non esegue Apache.(ad es.il mio FreeBSD specchio corre XSHTTPD)
• qualcuno più informato deve essere dedicata manutentore per un lungo periodo di tempo.Risolvere i problemi di aggiornamento/ do migrazioni etc.Perferably di più per ovvi motivi.
• un grande dolore sono distribuzioni Linux (e FreeBSD in misura minore), la maggior parte dei manutentori di *nix pacchetti non sono in grado di più "./configure;make;make install", e deve essere spoonfed con un vicino edificabile repository e ausiliaria file.
  • In distribuzione il confezionamento di FPC/Lazzaro è sempre stato importante, ed è ancora in aumento
  • Tutte le distribuzioni hanno le loro regole speciali sui metadati, depedancies, e come fonti devono essere pubblicati.In particolare Debian/Ubuntu è molto burocratico e lento.
  • La maggior parte non piace terzi auto-installatori in cima alla loro sistemi (dal momento che ignora le loro relative alle dipendenze di controllo)

Tutto questo porta ad un'efficace pratica che i propri strumenti in Pascal con un minimo di script funzionano meglio.Alcuni strumenti utilizzati:

• Gmake è utilizzato principalmente per parameterise il processo di costruzione di un al livello di directory, un successore, fpcmake (non proprio un make derivati, nonostante il nome) ha iniziato, ma la migrazione non è stata completata.
• Lattice e lattice per la conversione html (tex4ht, ma debian usa hevea) sono utilizzati nella documentazione di costruzione (non di documentazione della libreria)
• Il sito della comunità (netscape server di comunità che utilizza script TCL, un pesante complesso applicazione server) è stato un problema fin da quando è iniziato, ma specialmente ultimamente dal manutentore è diventato meno attivo.
• Mantis è stato un problema (specialmente la e-mail modulo di crash o lame server a causa del volume), ma è stata montata in forma durante i successivi aggiornamenti e il duro lavoro di diverse lazzaro devels.Attualmente si tratta di un decente cavallo di battaglia.
• lazarus.freepascal.org forum PHPBB OTOH è relativamente indolore, dal momento che un sacco di giovani che sanno come trattare con essa.
• Lo stesso vale per subversions (anche se il più avanzato scala ha bisogno di qualche regolazione, non tutti sono in profondità nella ins e outs del mergetracking)

Se qualcuno è stato veramente sul serio Maven, io di solito vorrei chiedere a lui:

• per CRITICIALLY indagare l'uso per il progetto.In modo molto concreto, con il programma e le stime di tempo.Gli uccelli d'occhio il livello del "tutto è possibile" panoramiche sono determinano inutile.
• Dare qualche pensiero sul futuro cambiamento di tecnologie utilizzate.Ogni tecnologia è sostituito, anche in casa, in 18 anni+ progetti.Una nuova tecnologia non deve effettuare migrazioni di altri componenti infrastrutturali rigido o coinvolti.La nuova tecnologia di porre fine a tutte le nuove tecnologie non esiste.
• Fare un piano di migrazione.La migrazione è spesso sottovalutato e sottostimato.
• E alla fine, c'è sempre il 1000000 di Euro di domanda, che farà la manutenzione quotidiana?

Tenete a mente che in una società si solo calcio la persona responsabile per l'applicazione server.Ma in un ambiente informale questo è il modo più difficile, specialmente a lungo termine, poiché la vita delle persone, delle occupazioni e del tempo dedicato al progetto variare.

Answer 2

Suona come un piano interessante, ma la comunità Delphi (e FPC ancora di più, immagino!) I valori di librerie come fonte di gran lunga più di librerie precompilate. Il consenso generale è che chiunque usi un solo binario biblioteca è uno sciocco, per due motivi:. Non si può risolvere eventuali bug che si trovano in essa, e le modifiche del compilatore si romperà la compatibilità