Melhor maneira de construir um sistema Plugin com Java

Como você implementaria um sistema Plugin para seu aplicativo Java?

É possível ter um sistema fácil de usar (para o desenvolvedor) que consiga o seguinte:

• Os usuários colocam seus plugins em um subdiretório do aplicativo
• O plug-in pode fornecer uma tela de configuração
• Se você usa uma estrutura, a licença é compatível com o desenvolvimento comercial?

Primeiro você precisa de uma interface que todos os plugins precisam implementar, por exemplo

public interface Plugin {
    public void load(PluginConfiguration pluginConfiguration);
    public void run();
    public void unload();
    public JComponent getConfigurationPage();
}

Os autores de plug-ins devem agrupar seus plug-ins em arquivos JAR. Seus aplicativos abrem o arquivo JAR e, em seguida, poderiam usar um atributo do manifesto JAR ou a lista de todos os arquivos no arquivo JAR para localizar a classe que implementa a interface do Plugin. Instanciar essa classe, o plugin está pronto para começar.

É claro que você também pode implementar algum tipo de sandbox para que o plug-in seja restrito ao que ele pode ou não fazer. Eu criei um pequeno aplicativo de teste (e publiquei um blog sobre ele ) que consiste em dois plug-ins, um dos quais tem acesso negado aos recursos locais.

Use OSGi .

É a base do sistema de plug-in Eclipse. Equinox é a implementação do Eclipse (EPL licenciado) e Felix é a implementação do Projeto Apache (licença pública Apache pública).

O Eclipse fornece um exemplo concreto de que o OSGi pode cobrir os pontos que você mencionou (ou você pode simplesmente construir seu aplicativo sobre o Eclipse RCP se desejar uma pilha completa do Eclipse / SWT / JFace).

Desde a versão 1.6, existe o java.util.ServiceLoader que pode ser usado se você quiser codificar seu próprio sistema simples.

Mas se você quiser algo além de recursos básicos, use uma das estruturas existentes.

Há também o JPF (Java Plugin Framework) .

Use PF4J . Tem suporte para Web, Spring e Wicket. Fácil de usar e criar aplicativos

Eu trabalhei no OSGi por uma semana - uma intensa, nada além da semana do OSGi. No final, foi como um pesadelo, mas eu aprendi muito.

Consegui fazer o OSGi funcionar (não é fácil, todos os exemplos estão desatualizados, tudo na rede tem pelo menos três anos, se não cinco), mas tive sérios problemas para integrá-lo a um projeto existente devido a problemas com o jar manifesta.

Em resumo, existem apenas algumas ferramentas obscuras usadas para criar manifestos e elas não estão bem documentadas (o BND Tools é dificilmente obscuro, mas foi projetado para um determinado processo no Eclipse). Além disso, a maioria das informações OSGi disponíveis não é direcionada a desenvolvedores de aplicativos que possuem um aplicativo de desktop existente.

Isso faz com que o contexto das informações fique embaçado ou inadequado. As postagens do blog de Neil Bartlett foram a maior ajuda, mas mesmo as que não conseguiram obter um sistema operacional (peguei algum código do tutorial Felix e o reuni para colocar a estrutura incorporada). Encontrei o rascunho do livro que ele publicou gratuitamente há alguns anos, o que é excelente, mas os exemplos no Eclipse não funcionam devido a alterações no suporte ao Eclipse OSGi.

Cada passo é um grande obstáculo. Vou tentar postar mais alguns detalhes aqui mais tarde.

Penso que recomendar o OSGi para resolver o problema mencionado acima é um conselho extremamente ruim. OSGi é "a escolha certa", mas para um cenário como o acima, acho que o JPF ou alguma estrutura minimalista doméstica é suficiente.

Anos atrás, comecei um projeto como esse e espero que em breve esteja pronto. Me inspirei em projetos como o NetBeans e o Eclipse, mas, enquanto isso, mudou para algo um pouco diferente. O OSGi parece uma boa escolha agora, mas não tive a chance de compará-lo com o meu projeto. É semelhante ao JPF mencionado acima, mas ao mesmo tempo diferente em muitos aspectos.

A idéia básica que me motivou é ser o mais fácil possível para criar aplicativos Java, sem separação entre aplicativos da Web, aplicativos de desktop ou aplicativos de applet / JWS (é claro que isso ainda não cobre a interface do usuário) como uma funcionalidade principal.

Criei o projeto com alguns objetivos em mente:

• não importa se você cria um aplicativo da Web ou um aplicativo de desktop, você deve iniciar o aplicativo da mesma maneira, um método principal simples, sem declaração sofisticada do web.xml (não que eu seja contra ter um descritor da Web padrão, mas não funciona bem com um sistema de plug-in, onde você adiciona "servlets" - eu os chamo de RequestHandler (s) - dinâmicos à sua vontade).
• fácil conectar "extensões" em torno de um "ponto de extensão" - algo do Eclipse, mas com uma abordagem diferente.
• auto-implementável, uma vez que todos os plugins são registrados (arquivos XML), o aplicativo deve ser auto-implementável independentemente do sistema de compilação - é claro que há uma tarefa Ant e um Maven MOJO, que são os links para o mundo externo, mas no final, chama o aplicativo e instrui-o a se auto-implantar em um local específico.
• emprestado do Maven, ele pode fazer o download do código dos repositórios (incluindo os repositórios Maven 1 e 2) para que seu aplicativo possa ser implantado como um único jar pequeno, desde que você tenha acesso aos repositórios (útil em algum momento e, basicamente, fornece suporte para auto- atualizações - você não gosta da idéia de ser notificado pelo seu aplicativo da web que há uma versão mais recente, foi baixada e precisa apenas da sua permissão para instalá-la? Eu sei que amo isso).
• monitoramento básico de aplicativos sobre a integridade do sistema, notificações por email em caso de falhas