The Atlassian plugin system has been in Atlassian products for years, allowing developers to add new features to Atlassian applications dynamically in some cases (Confluence). However, the two main problems with it were: * No defined boundary between the application and plugins, causing plugins to break on application upgrades as well as buggy plugins using the internal application classes in ways they weren't meant to be used * Plugins cannot depend on other plugins reliably.
The last one was particularly painful for projects I've been working in as we've been trying to basically build new applications on top of the existing applications using plugins, and not having a reliable way to have plugin dependencies has been a real blocker. The first issue hampers our plugin community and causes a significant support load. Therefore, I build Atlassian Plugins 2.0 to resolve these issues by building the framework on OSGi. OSGi allows our applications to say exactly what classes and services are available to plugins, and has built-in support for inter-bundle dependencies. At this point, we are positioning this to be a solution for user plugins as well as our internal bundled plugins, but there is movement for rewriting bits of the application architecture over to use plugins. Therefore, we are using OSGi in a hybrid sense, because the usual integration path is to build the whole application as OSGi bundles using a Servlet bridge or get rid of the app server altogether and use an OSGi container directly. This allows us to leave the main application alone and migrate to OSGi where it makes sense. Our medium term goal is to build a plugin market place, where administrators can browse plugins and install them from a remote repository with one click. This feature is available now on Confluence and soon on JIRA, but we want to support this in all our products consistently. Our first draft of plugin documentation can be found here: http://confluence.atlassian.com/display/PLUGINFRAMEWORK/Plugin+Framework+Documentation Don On Fri, Sep 12, 2008 at 11:25 AM, Jeromy Evans <[EMAIL PROTECTED]> wrote: > Thanks for the update. Is the purpose of the plugin system to make it > easier for administrators to bring plugins into their deployment at > run-time, or more about minimising conflicts between plugin versions? And > are you pulling plugins from a repository (eg. browse and select compatible > versions much like, say, IntelliJ)? > > Interesting. In my use-case the plugins (bundles) would contain S2 > actions/packages and Entities. > > Don Brown wrote: >> >> The latest status is I built a plugin system around OSGi for Atlassian >> and it is in the process of being rolled out. Basically, it utilizes >> a hybrid approach where the main webapp is a normal webapp, but >> plugins can be installed on it dynamically via OSGi. I have the OK to >> open source it, but I want to have something in mind to use it with >> first. Archiva, the Maven proxy, is looking to add a plugin system, >> and since James, a fellow Atlassian, is a committer, I might start >> there. They use WebWork 2 right now, so it may involve a migration to >> Struts 2, we'll see... >> >> Don >> >> On Fri, Sep 12, 2008 at 10:33 AM, Jeromy Evans >> <[EMAIL PROTECTED]> wrote: >> >>> >>> Has anyone given any more thought to an OSGI container embedded within >>> Struts2? >>> >>> I ask because I growing to hate having to build and deploy entire war >>> files >>> and regularly restart Containers. It seems far behind alternative >>> technologies. >>> >>> Is it conceivable that: >>> - the container provides the infrastructure (and almost never restarts); >>> - S2 provides a standard deployment/development environment (and is never >>> undeployed) >>> - the OSGI container within S2 provides the ability to deploy/undeploy >>> bundles within that environment >>> >>> Then, as an S2 developer I package my application up as sensible bundles >>> and >>> deploy/update them as needed, so I'm working with tiny little jars >>> instead >>> of massive wars. >>> >>> Some complex discovery is required with each bundle deployment but >>> achievable. I'd much prefer something like this rather than S2 apps >>> themselves being deployed within an OSGI container. >>> >>> Is this along the lines with your latest thoughts Don or Musachy or have >>> you >>> moved on? >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
