Pergunta

Apache Maven é uma ferramenta de construção e dependência gestão muito popular no ecosphere open source Java. Eu fiz alguns testes para descobrir se ele pode lidar com compilado Free Pascal / Delphi e achei fácil de implementar. Portanto, seria possível

  • Datas de bibliotecas de código aberto pré-compilados para Free Pascal (ou Delphi) em um público Maven repositório
  • incluem metadados neste repositório que contém informações de dependência
  • usar Maven na linha de comando para baixar a biblioteca de código aberto a partir do repositório público e, automaticamente, resolver todas as dependências
  • repositórios locais, trabalhando como proxies, poderia ser usado para armazenar em cache binários usados ??com frequência
  • geração de soma de verificação automática e verificação (fornecido pelo Maven) reduziria o risco de baixar os binários corrompidos
  • arquivos
  • código fonte e documentação até mesmo poderia ser fornecido com os binários
  • binários podem ser fornecidos com ou sem informações de depuração
  • servidores de integração contínua como Hudson , TeamCity ou CruiseControl pode ser usado para projetos de construção sempre que as alterações foram submetidos ao sistema de controle de origem e notificar os desenvolvedores sobre erros de compilação

Esta forma de gerenciamento de dependência pode ser muito benéfico para projetos de código aberto que usam muitas bibliotecas de terceiros com dependências complexas. Seria evitar conflitos típicos causados ??pelo uso de versões erradas.

Para o desenvolvedor, o fluxo de trabalho para edição e construção de um projeto seria reduzido ao mínimo:

  • checkout da fonte do projeto do sistema de controle de versão interna
  • editar o arquivo fonte (s)
  • mvn package correr para baixar automaticamente todas as bibliotecas de terceiros necessários (unidades pré-compilados) se eles ainda não estão no repositório local da estação de trabalho
  • compilar e executar

O arquivo só adicional para o Apache Maven que é exigido na pasta do projeto é o arquivo pom.xml contendo as informações do projeto.

Editar: enquanto Maven é utilizável para algumas das tarefas necessárias, a implementação de uma solução como Maven em nativa Free Pascal teria algumas vantagens: no Java SDK necessário, suporte para todas as plataformas de desenvolvimento em que Free Pascal é acessível, manutenção e desenvolvimento do plugin em Pascal.

O uso de um Maven-como ferramenta não seria útil para projetos de código aberto única -. Projetos comerciais podem acessar e usar os artefatos em repositórios públicos Maven, da mesma forma, assim

características

Maven estão listados no http://maven.apache.org/maven-features.html


Update:

um caso de uso poderia ser a construção de Lázaro, onde Maven iria baixar todas as bibliotecas necessárias e invocar o compilador com os argumentos caminho de construção necessários. Mudanças nas dependências em níveis mais baixos seria propagada automaticamente até a compilação pai.

benefícios possíveis:

  • menos tempo necessário para configurar um novo trabalho estação, nenhuma instalação manual de bibliotecas de terceiros necessário
  • menos erros causados ??pela biblioteca errada versões, a detecção de versão conflitos (por exemplo, se dois bibliotecas dependem de diferentes versões de uma terceira biblioteca)
  • artefatos que são criados inhouse pode ser adicionado ao local do Maven repositório e compartilhada entre desenvolvedores e projeto, central armazenamento de todos os artefactos com metadados
  • compilações são reprodutíveis, apenas usando a mesma fonte e projeto arquivo de metadados (pom.xml)
  • pode reduzir o tempo de desenvolvimento e aumentar a estabilidade do projeto

Atualização # 2: FPMake

FPMake sistema de compilação para Free Pascal parece ser uma ferramenta com grande potencial, em muitos detalhes que é bastante semelhante ao Maven:

  • FPMake é um sistema de construção com base pascal desenvolvido para e distribuído com FPC
  • FPMake padroniza o edifício através da definição de alguns limites, como diretórios padrão
  • o fppkg <packagename> comando irá procurar em um banco de dados para o pacote, extraí-lo, e depois fpmake.pp compilação e executá-lo
  • tem alvos padrões de construção (limpo, construção, instalação, ...)
  • ele pode criar um arquivo 'manifesto' adequado para importação para um repositório (como mvn deploy ou mvn install), o manifesto é um arquivo XML que se parece muito semelhante a um pom.xml em Maven:

FPMake arquivo de manifesto:

      <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>

Nenhuma solução correta

Outras dicas

Freepascal vem trabalhando em um sistema de pacotes própria em um cruzamento entre do apt-get e FreeBSD estilo. (Download source / build / instalar automaticamente), chamado fppkg. No entanto trabalho estagnou. Pessoas Investir tempo são o gargalo, não as pessoas que querem escolher ferramentas.

Quanto Maven vai, eu não gosto de ferramentas auxilary que a instalação necessidade de grandes tempos de execução externos. Pode ser bom para um aplicativo grande grande (como o Open Office), mas não para uma util.

Eu também prefiro uma ferramenta que é projetado para a realidade FPC e fluxo de trabalho. ferramentas de documentação, ferramentas de construção, sistemas de transferência, sistemas testsuite já estão todos lá, ele só precisa de uma pessoa que dedica muito tempo para ela, para que isso aconteça.

Alguns problemas típicos quando introduzindo uma nova tecnologia em um projeto como FPC, e por isso tem uma tendência a fazer suas próprias ferramentas:

  • necessidade de formar mais de 20 committers em tempo parcial.
  • A linguagem de programação comum apenas pode assumir é Free Pascal. funcionamento interno Mesmo Delphi não pode ser tomada como garantida a ser conhecido (muitas committers veio diretamente para FPC ou mesmo ainda via TP ou um Mac Pascal)
    • Obviamente que faz algo com plugins em um idioma diferente irritante.
  • Bash script é um segundo próximo. (G) fazer terceiro, mas já a magnitude menos.
  • Todos os servidores são * nix-like (FreeBSD, OS X, Linux), mas nem todos executar o Apache. (Por exemplo, meu espelho FreeBSD é executado XSHTTPD)
  • alguém mais qualificado deve ser mantenedor dedicado por um longo tempo. Corrigir problemas, atualizar / fazer migrações etc. perferably mais de um por razões óbvias.
  • uma grande dor são distribuições de Linux (e FreeBSD em menor grau), a maioria dos mantenedores de pacotes * nix não são capazes de mais do que "./configure;make;make instalar", e deve ser spoonfed com um repositório edificável perto e arquivos auxilary.
    • embalagem In-distribuição de FPC / Lazarus sempre foi importante, e ainda está aumentando
    • Todas as distribuições têm suas próprias regras especiais sobre metadados, depedancies, e como fontes devem ser publicados. Particularmente Debian / Ubuntu é muito burocrático e lento.
    • A maioria não gosta de festa auto-instaladores terceiros no topo de seus sistemas (desde que ignora seu controle dependência)

Isso tudo leva à prática eficaz que as ferramentas próprias em Pascal com o trabalho de scripting mínima melhor. Algumas ferramentas utilizadas:

  • gmake é usado principalmente para parametrizar o processo de construção em um por diretório de nível, um sucessor, fpcmake (não é realmente um derivado make apesar do nome) começou, mas a migração não foi concluída.
  • Latex e um látex para html conversão (TeX4ht, mas usa o Debian seringueira) são utilizados na construção de documentação (a documentação não biblioteca)
  • O site da comunidade (servidor da comunidade Netscape que usa TCL script, um servidor de aplicação complexa pesado) tem sido um problema desde que começou, mas especialmente ultimamente, desde que o mantenedor se tornou menos ativo.
  • Mantis tem sido um problema (especialmente o módulo de e-mail iria falhar ou coxo do servidor devido ao volume), mas foi chicoteado em forma durante sucessivas atualizações e trabalho árduo de vários devels Lázaro. Atualmente ele é um burro de carga decente.
  • lazarus.freepascal.org PHPBB fórum OTOH é relativamente indolor, pois muitas das pessoas mais jovens sabem como lidar com ele.
  • O mesmo vale para subversões (embora a escala mais avançado precisa de alguns ajustes, nem todo mundo é profundamente nos meandros do mergetracking)

Se alguém era realmente sério sobre Maven, eu normalmente iria perguntar-lhe:

  • para CRITICIALLY investigar o uso para o projeto. De um modo muito concreto, com estimativas de cronograma e de tempo. nível birds-eye "possíveis de tudo" visões gerais são essencialmente inúteis.
  • Dar algum pensamento sobre o futuro mudança de tecnologias utilizadas. Toda tecnologia é o eventovamente substituído, mesmo as in-house, em projectos de 18 anos +. Uma nova tecnologia não deve fazer migrações de outros componentes de infra-estrutura difícil ou envolvidos. A nova tecnologia para acabar com todas as novas tecnologias não existe.
  • Faça um plano de migração. A migração é muitas vezes subestimado e subestimado.
  • E no final, há sempre a questão 1000000 Euro, que irá fazer a manutenção diária?

Tenha em mente que em uma empresa que acabou de chutar a pessoa responsável pelo servidor de aplicativos. Mas em um ambiente informal este é o caminho mais difícil, especialmente a longo prazo, uma vez que a vida das pessoas, ocupações e tempo gasto no projeto variar.

soa como um plano interessante, mas a comunidade Delphi (e FPC ainda mais, eu imagino!) Valoriza bibliotecas como fonte de muito mais do que bibliotecas pré-compiladas. O consenso geral é que qualquer um que usa uma biblioteca só de binário é um tolo, por duas razões:. Você não pode corrigir todos os erros que você encontra nela, e alterações do compilador irá quebrar a compatibilidade

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top