ventanas - La mejor forma de crear un sistema de complementos con Java
sistema de complemento resumen (8)
¿Cómo implementarías un plugin-system para tu 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 usa un marco, ¿es la licencia compatible con el desarrollo comercial?
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 ya sea JPF o algún marco minimalista de cosecha propia es suficiente.
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 funciones básicas, use uno de los marcos existentes.
Hace años comencé un proyecto así 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 al JPF mencionado anteriormente, pero al mismo tiempo es diferente en muchos aspectos.
La idea básica que me motivó es ser lo más fácil posible para crear aplicaciones Java, sin separación entre aplicaciones web, aplicaciones de escritorio o aplicaciones de applet / JWS (por supuesto, esto aún no cubre la interfaz de usuario) como una funcionalidad central.
Construí el proyecto con algunos objetivos en mi mente:
- no importa si construyes una aplicación web o una aplicación de escritorio, deberías iniciar la aplicación de la misma manera, un método principal sencillo, sin declaración web.xml sofisticada (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 voluntad).
- es fácil conectar "extensiones" alrededor de un "punto de extensión", algo de Eclipse pero con un enfoque diferente.
- autodesplegable, dado que todos los complementos están registrados (archivos XML), la aplicación debe ser autodescargable independientemente del sistema de compilación; por supuesto, hay una tarea Ant y un Maven MOJO que son los enlaces con el mundo propio, pero en el Al final, llama a la aplicación y le indica que se autodesplegue en una ubicación específica.
- tomado de Maven, puede descargar código de repositorios (incluidos repositorios Maven 1 y 2) para que su aplicación se pueda desplegar como un único contenedor pequeño siempre que tenga acceso a los repositorios (útil en algún momento, y básicamente esto proporciona soporte para auto- actualizaciones: ¿no te encanta la idea de que tu aplicación web te notifique que hay una versión más nueva, que se descargó y solo necesita tu permiso para instalarla? Sé que eso me encanta).
- monitorización básica de aplicaciones sobre la salud del sistema, notificaciones por correo electrónico en caso de fallas
Primero necesitas una interfaz que todos los complementos necesiten implementar, por ejemplo
public interface Plugin {
public void load(PluginConfiguration pluginConfiguration);
public void run();
public void unload();
public JComponent getConfigurationPage();
}
Los autores de complementos deberían agrupar sus complementos en archivos JAR. Sus aplicaciones abren el archivo JAR y luego pueden 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 de Complemento. Crea una instancia de 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 plugin esté restringido en lo que puede y no puede hacer. Creé una pequeña aplicación de prueba (y blogéa sobre ella ) que consta de dos complementos, uno de los cuales no tiene acceso a los recursos locales.
También hay JPF (Java Plugin Framework) .
Trabajé en OSGi por una semana, una semana intensa, nada más que OSGi. Al final fue como un mal sueño, pero aprendí mucho.
Pude hacer funcionar OSGi (no es fácil, todos los ejemplos están desactualizados, todo en la red tiene al menos tres años, sino cinco), pero tuve serios problemas para integrarlo en un proyecto existente debido a problemas con el jar manifiestos
En resumen, solo hay unas pocas herramientas poco conocidas para construir manifiestos y no están bien documentadas (BND Tools no es oscuro, pero está diseñado para un determinado proceso en Eclipse). Además, la mayoría de la información OSGi disponible no está dirigida a desarrolladores de aplicaciones que tienen una aplicación de escritorio existente.
Esto hace que gran parte del contexto para la información sea nebulosa o inapropiada. Las publicaciones en el blog de Neil Bartlett fueron de gran ayuda, pero incluso aquellas no lograron tener un sistema en funcionamiento (cogí un código del tutorial de Félix y lo armé para obtener el marco integrado). Encontré el borrador de su libro que publicó gratuitamente hace años, que es excelente, pero los ejemplos en Eclipse no funcionan debido a los cambios en el soporte de Eclipse OSGi.
Cada paso es un gran obstáculo. Trataré de publicar más detalles aquí más adelante.
Use OSGi .
Es la base del sistema de plug-in de Eclipse. Equinox es la implementación de Eclipse (EPL con licencia) y Felix es la implementación del Proyecto Apache (licencia pública de Apache con licencia).
Eclipse proporciona un ejemplo concreto de que OSGi puede cubrir los puntos que usted mencionó (o puede simplemente construir su aplicación sobre Eclipse RCP si desea una pila completa de Eclipse / SWT / JFace).
Use PF4J. Tiene soporte para Web, Spring y Wicket. Fácil de usar y construir las aplicaciones