What is Apache Geronimo?
Geronimo is an open source, J2EE 1.4-compliant application server developed and maintained by the Apache Software Foundation. For Geronimo 1.1, you can find several distributions including a fully-certified J2EE stack and a lighter-weight server based on a web container without things like EJB and CORBA support.

OK, but what are plugins?
Plugins are applications that run in Geronimo, or services that run in Geronimo (either services that do something on their own or services that are available to be used by other applications or services within Geronimo). Then a plugin is specially packaged so you can easily install it directly from the main plugin web site (or a private web site you set up for the same purpose). When you install a plugin, Geronimo will automatically download and install all the dependencies (JARs or other plugins) required by the plugin you're installing. It makes the installation process as painless as possible.

Why do you have plugins? e.g. Can't I just distribute a WAR file?
Plugins make the process of installing an application or service easy and explicit. First, installing a plugin automatically downloads any dependencies (JARs or other plugins) that are not already available in the server. Second, if there are prerequisites (such as: you must create a database pool for the plugin to use), the plugin will tell you about them and refuse to install until they're ready. Third, if you submit a plugin to the standard Geronimo plugin repository, you'll get a little free publicity when people go to look for available Geronimo plugins. Finally, not every WAR file can be deployed as-is in Geronimo (that is, it may lack a necessary Geronimo XML deployment plan to configure resource references, etc.). However, you have to deploy a service or application in Geronimo to make a plugin out of it, so users have some assurance that a plugin is complete and will install in Geronimo with no problems.

What can plugins do?
The reverse of the next answer. :) They can integrate outside products (example: a reporting server or scheduling server), they can add handling for new types of deployments (a Spring archive or Hibernate archive), they can access other components running in the server (including, for example, thread pools and security and transaction controls), they can depend on 3rd party JARs or other plugins (and applications can depend on them), they can replace previous plugins or versions with updated versions, and probably more that we haven't thought of yet.

What can plugins not do?
They can't add handling for different products to the JMS, or security realm screens of the console. They can't insert code into the processing chain for requests (EJB, Web, etc.). There is no way to provide code that runs exactly once during the plugin installation process (though you can provide code that runs every time the plugin is started and just have it flag itself after the first time it's run).

It's technically possible for a plugin to install features into the admin console, but it's not for the faint of heart (and the user needs to either restart the server or hit a specially-crafted URL to get the new screens to show up).

How hard is it to create plugins for Geronimo?
The main work is getting your application or service running in Geronimo in the first place (and hopefully that is easy enough!). Once it is running, you go to the admin console and select the option to export a plugin. There's a form you need to fill out with some information about the plugin (a human-readable name, description, etc.), and then two clicks later it gives you a download file that you save to disk and that's your plugin!

Do you have to restart the server to install a plugin?
No, normally you do not. Even if you're installing major features or upgrading an existing plugin or module. Generally the plugin (and any dependencies) are downloaded, installed, and started on the spot.

You must be lying! Or, define "normally".
Let's say you've made a plugin for a web application, and I deploy it in a very lightweight web-container-only distribution of Geronimo. For the next version of your web app, you add JMS features, so you have a JMS resource module that your web application now depends on. I install the new version of your web app plugin. What happens? The application plugin is downloaded and installed, then the JMS resource it depends on is downloaded and installed, then the ActiveMQ JMS broker is downloaded and installed, then those three modules are started, then the old version of your application is deleted. No restart. On the fly, we added JMS, started a JMS server, activated JMS destinations and connection factories, and upgraded your application. Pretty cool, huh?

Whoa! But is there a way to install a group of plugins together?
Yes, you can create a "plugin list" which looks kind of like a plugin except it has no code itself -- only a list of dependencies which will be installed when the "plugin list" is installed. After installation, you no longer know a list was used -- it looks the same as if all the plugins in the list were installed individually.

Can you install plugins to a server if it is not online or is behind a proxy server?
Not unless the Geronimo server has all the dependencies for that plugin available already. You could manually download and install all the dependencies, though that might be quite tedious.

However, there is one workaround. One Geronimo server can install plugins directly from another Geronimo server. So you could, for example, install all the plugins (which will bring down their dependencies) on your laptop with your home or coffee shop internet connection, and then bring it in to work and have your work server install all the plugins from the Geronimo installation on your laptop.

We're considering creating larger packages of plugins+dependencies for a future release.