La mejor manera de construir un sistema de complementos con Java

¿Cómo implementaría un sistema Plugin para su aplicación Java?

¿Es posible tener un sistema fácil de usar (para el desarrollador) que logre lo siguiente:

• Los usuarios colocan sus complementos en un subdirectorio de la aplicación
• El complemento puede proporcionar una pantalla de configuración
• Si utiliza un marco, ¿es la licencia compatible con el desarrollo comercial?

Primero necesita una interfaz que todos los complementos deben implementar, por ejemplo

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

Los autores de complementos deben agrupar sus complementos en archivos JAR. Sus aplicaciones abren el archivo JAR y luego podrían usar un atributo del manifiesto JAR o la lista de todos los archivos en el archivo JAR para encontrar la clase que implementa su interfaz Plugin. Instancia esa clase, el complemento está listo para funcionar.

Por supuesto, es posible que también desee implementar algún tipo de sandboxing para que el complemento esté restringido en lo que puede y no puede hacer. Creé una pequeña aplicación de prueba (y escribí en un blog sobre ella ) que consta de dos complementos, uno de los cuales no tiene acceso a los recursos locales.

Usa OSGi .

Es la base del sistema de complemento Eclipse. Equinox es la implementación de Eclipse (EPL con licencia) y Felix es la implementación del Proyecto Apache (Licencia pública Apache con licencia).

Eclipse proporciona un ejemplo concreto de que OSGi puede cubrir los puntos que mencionó (o simplemente podría construir su aplicación sobre Eclipse RCP si desea una pila completa de Eclipse / SWT / JFace).

Desde 1.6, ha habido java.util.ServiceLoader que se puede usar si desea codificar su propio sistema simple.

Pero si desea algo más que características básicas, use uno de los marcos existentes.

También hay JPF (Java Plugin Framework) .

Use PF4J . Tiene soporte para Web, Spring y Wicket. Fácil de usar y construir las aplicaciones.

Trabajé en OSGi durante una semana, una semana intensa, nada más que OSGi. Al final fue como un mal sueño, pero aprendí mucho.

Pude hacer que OSGi funcionara (no es fácil, todos los ejemplos están desactualizados, todo en la red tiene al menos tres años, si no cinco), pero tuve serios problemas para integrarlo en un proyecto existente debido a problemas con el jar se manifiesta.

En resumen, solo se usan algunas herramientas oscuras para crear manifiestos y no están bien documentadas (BND Tools no es oscura, pero está diseñada para cierto proceso en Eclipse). Además, la mayoría de la información OSGi disponible no está dirigida a desarrolladores de aplicaciones que tengan una aplicación de escritorio existente.

Esto hace que gran parte del contexto de la información sea confuso o inapropiado. Las publicaciones de blog de Neil Bartlett fueron de gran ayuda, pero incluso esas no lograron obtener un sistema que funcionara (tomé un código del tutorial de Felix y lo ensamblé para que el marco incrustado funcionara). Encontré el borrador de su libro que publicó gratis hace años, lo cual es excelente, pero los ejemplos en Eclipse no funcionan debido a los cambios en el soporte de Eclipse OSGi.

Cada paso es un obstáculo importante. Intentaré publicar más detalles aquí más adelante.

Creo que recomendar OSGi para resolver el problema mencionado anteriormente es un consejo extremadamente pobre. OSGi es "la elección correcta", pero para un escenario como el anterior, creo que JPF o algún marco minimalista de cosecha propia es suficiente.

Hace años comencé un proyecto como ese y espero que pronto esté listo. Me inspiré en proyectos como NetBeans y Eclipse, pero mientras tanto cambió a algo un poco diferente. OSGi parece una buena opción ahora, pero no tuve la oportunidad de compararlo con mi proyecto. Es similar a JPF mencionado anteriormente, pero al mismo tiempo diferente en muchos aspectos.

La idea básica que me motivó es ser lo más fácil posible para construir una aplicación Java, sin separación entre aplicaciones web, aplicaciones de escritorio o aplicaciones de applet / JWS (por supuesto, esto no cubre la interfaz de usuario, todavía) como una funcionalidad central.

Construí el proyecto con algunos objetivos en mente:

• no importa si crea una aplicación web o una aplicación de escritorio, debe iniciar la aplicación de la misma manera, un método principal simple, sin declaración web.xml elegante (no es que esté en contra de tener un descriptor web estándar, pero no funciona bien con un sistema de complemento, donde agrega "servlets" - los llamo RequestHandler (s) - dinámico a su voluntad).
• "extensiones" fáciles de conectar alrededor de un "punto de extensión", algo de Eclipse pero un enfoque diferente.
• autodesplegable, ya que todos los complementos están registrados (archivos XML), la aplicación debe ser autodesplegable independientemente del sistema de compilación; por supuesto, hay una tarea Ant y un MOJO Maven que son los enlaces con el mundo de nuestro lado, pero en el Al finalizar, llama a la aplicación y le indica que se autodespliegue en una ubicación específica.
• prestado de Maven, puede descargar el código de los repositorios (incluidos los repositorios Maven 1 y 2) para que su aplicación se pueda implementar como un único contenedor pequeño siempre que tenga acceso a los repositorios (útil alguna vez, y básicamente esto proporciona soporte para auto- actualizaciones: ¿no le gusta la idea de que su aplicación web le notifique que hay una versión más nueva, se descargó y solo necesita su permiso para instalarla? Sé que me encanta).
• monitoreo básico de la aplicación sobre el estado del sistema, notificaciones por correo electrónico en caso de fallas