Grouper Developers Forum

[dan <>]

Hi all,

I just thought I'd share a few notes from my experience integrating grouper-1.1, signet-1.0.3 and ldappc-1.0. Hopefully these will be useful to you.

- The code is fine, I haven't stumbled across any showstopping bugs, but I didn't expect to considering this code is already deplyed in a number of production contexts.
- The build and installation process it quite tricky and inconsistent across projects, JAR versioning is problematic, and there's a real need (as mentioned by others) for projects to coordinate and publish information about compatible versions. Details follow:

-- ldappc builds into ./build/ldappc, grouper builds into ../dist/grouper, grouper-ui builds into ./webapp, signet builds into  ./dist/signet-1.0.1 and ./dist/signet-1.0.1/webapp
-- signet's gui is distributed as a WAR, though you can force it to run from its webapp dir by creating a file in [tomcat]/conf/Catalina/localhost/signet.xml like this:

<Context path="/signet" docBase="/path/to/signet-1.0.3/dist/signet-1.0.1/webapp/signet"
        debug="0" privileged="false" reloadable="false" swallowOutput="true"
        />

however this file is deleted every time you rebuild if Tomcat is still running, because it undeploys the context. Grouper, on the other hand, creates its own context file on every rebuild, so no problems occur.

-- grouper connects to the JDBC DB and initialises it from the ant script. Signet ships with sql files that must be used to initialise the DB by hand.
-- grouper is split into grouper and grouper-ui. Signet combines libs and ui into one project. Probably need to pick one approach? Also, a change in grouper requires rebuilding and redistributing grouper, and then rebuilding and reinstalling grouper-ui. If grouper-ui just knew where to find grouper without having to copy and rebuild using the grouper libs, the second step could be avoided.
-- using grouper groups from signet requires copying the grouper.jar and grouper-libs.jar (as well as all the config files). However, libs within grouper-libs.jar are incompatible versions from the ones signet requires, 
e.g. sources 0.2.1 vs. sources 0.1
-- using signet and grouper sources from ldappc requires copying signet and grouper jars, plus commons-logging, db drivers etc from each, into ldappc's classpath.
-- built-in user authentication is done differently between grouper and signet, 
e.g. grouper's GrouperSystem and signet's proxy which must be used to delegate authority to a user already in the DB.

- Connection parameters for various databases and LDAP repositories are specified in many places, 
e.g. grouper.hibernate.properties vs. sources.xml vs. signet's hibernate.cfg.xml, buildSignet.properties and more. Not only is there redundant information here, but it's in several different configuration file formats. It would be great to have a single format (
e.g. hibernate.xml, or generate hibernate's config dynamically from sources.xml) and simply depend on that. What's more, such a configuration file is likely to be shared between signet, grouper, ldappc and others, and so should be centralised under I2MI-Common, upon which all projects should depend. This way, we could just include a single properties entry for each project, 
i2mi.directory, which points to the base of the i2mi-common directory. Individual projects and then find their configuration information under this directory. 

I2MI versions could then specify grouper/signet/ldappc versions that they support. Dependency resolution is then quite simple. Installation is also simple - build the signet/grouper/ldappc classes into the single i2mi directory. You could have a structure like this (for example, under /opt/i2mi):

/i2mi-1.0 (mandates grouper-1.1 and signet-1.0.1, for example)
  /common
    /lib (libs go here)
    /conf (sources.xml etc)
  /grouper
  /grouper-ui
  /signet
  /signet-ui
  /ldappc

/i2mi-1.1 (mandates grouper-1.2 and signet-1.1)
  /...

In summary, a lot of this trickiness could be alleviated just by deciding on:
1. standard build procedure and commands, e.g. build, test, dist, install, where install implies db-init
2. explicit dependencies and testing of supported version pairs under a common i2mi-common version, with same lib versions for both signet and grouper
3. standard way of deploying and running webapps, e.g. in-place or war
4. centralised, single subjects.xml

I'm sure there's more, but I just wanted to provide feedback while it's fresh in my mind. I'm sure you're already aware of and working on a lot of this stuff, but I figured it can't hurt to get another opinion ;-)

Thanks,
Dan