Shibboleth Developers

[Tom Scavo <>]

On 7/5/05, Chad La Joie 
<>
 wrote:
> 
> Each custom extension (or groups of extensions) would create a directory
> within the "custom" directory. These extension directories would have
> the following directory structure
> 
>   <extension_directory>
>      etc/
>      lib/
>      src/
>      test/
>      build.properties

Do you mean tests/ (plural) for consistency?

> The "src" directory would contains your java sources for the extensions.
>  The "test" directory would contain any unit tests for them. The "etc"
> directory would contain any number of directories that would simply be
> copied in to the resulting extension jar, you would put any non-source
> files that you wanted available on the class path in here (config files,
> XML schemas, etc). 

Instead of an etc/ directory, wouldn't an include file be more
flexible?  Then the paths could be relative or absolute.  (Absolute
paths are an important requirement, at least for the extension I have
in mind.)

> The "lib" directory would contain any 3rd party
> libraries you need for your stuff.  Additional directories can be
> included (documentation, config files that go somewhere else, etc) and
> they'll just be ignored.  The build.properties file would contain a
> single property; the name of the resulting jar.

What would be the name of this property and would it be okay to have
other properties in the build.properties file?  For example, is it
okay to override idp.deployment.descriptor and/or
sp.deployment.descriptor in the extension build.properties file?

> When the IdP or SP was built it would compile each extension in turn

In what order?  What if one extension depends upon another?

> (ensuring all the Shib and 3rd party extension classes/libs are on the
> classpath) and place the resulting extension jar, and all 3rd party jars
> (those in extension_directory/lib) into a lib directory in the "custom"
> directory.  Then, when the WARs were built for the IdP and SP, these jar
> would be scooped up and put in the appropriate place.  A by product of
> this approach is a greatly simplified means of including custom
> extension; compiling them in some fashion and just placing the resulting
> jar(s) in the custom/lib directory.

What is done with the unit tests in tests/?

> Two issues with this approach.  First, if different extensions use
> different versions of the same 3rd party jar you'll get class conflicts.
>  This would be true whether the Shib build did any of this special stuff
> or not.  Second, extension authors are locked in to this source-tree
> structure.  For most extensions this is probably just fine, for more
> complicated extensions this may not be good.  I had discussed with a
> couple people some idea for making this more flexible but ultimately we
> decided that the additional complexity for everything BUT the extension
> (and probably even for the extension) just wasn't worth it.  So, for
> these special extensions, they can create their own build process and
> just place their jar(s) in the custom/lib directory.

Don't know if I'm in the latter category, but two things come to mind:

1) What if the extension wanted to supply a custom user ARP?

2) How will the extension pre-process configuration files?  For
example, what if the extension needed to do a custom variable
substitution (similar to $SHIB_HOME$)?  (By the way, $SHIB_HOME$ needs
to be changed to $IDP_HOME$ or $SP_HOME$ so that it agrees with the
new property names in build.properties.)

Thanks,
Tom