In 2007 Grouper had several plugins, maintained by core developers: GSH, loader, ldappc, unresolvable-subject-deletion-utility.

It was nice to have the separation of duties, but there were some serious problems with development, installing, and support, such as:

1. Changes are made to the API, and the other plugins arent checked out, so code is committed with compile errors

2. Changes are made, and the API Junits are run, but the plugin junits arent run, so code is committed and broken

3. Does plugin version 1.X work with API 1.Y?  Does 1.X work with 1.Z?  It was DLL-hell, and we addressed this by tagging / branching / releasing all plugins together, with the assumption that all or none would be upgraded at once

4. The build script was like speghetti: difficult to build / package all plugins especially with external systems like the UI and WS

5. Users had more steps to do to upgrade, and this caused confusion

6. It is more difficult to setup a dev env if there are many projects with dependencies etc

7. Each plugin might need more config files etc (well, in this case most have their own config file anyway )

8. It is less clear how to kick off a plugin.  And kicking things off with ant is confusing

We have spent a lot of time from 2007-2009 to consolidate and make things much easier to develop, deploy, support, and upgrade.  Currently we have the API project (which includes the above "plugins"), the web services project (which has a lot of WS specific jars), and the UI (which has a lot of UI specific jars, and is separate in duties to the WS).  We also have the grouperClient which has no jar dependencies.  The subject API and morphString are separate projects.

Over the past couple of years, we have received compliments on how much easier it is to install/upgrade.

I believe this proves that unnecessary plugins are painful, and consolidating where it makes sense (e.g. if not adding another 20 jars), is a good thing.

Chris