Shibboleth Developers

[Walter Hoehn <>]

On Jul 5, 2005, at 3:31 PM, Chad La Joie wrote:

> Tom Scavo wrote:
>
> > > When the IdP or SP was built it would compile each extension in turn
> > In what order?  What if one extension depends upon another?
>
> There is no implied order.  While I agree that this could be  
> helpful in the future, it's a HUGE pain to do and just not going to  
> happen right now.  You have to go outside Ant and use something  
> like IVY or Maven to manage this and we're trying to get the "low  
> hanging fruit" with this.

Totally agree.

> > > 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?
>
> Extensions don't supply this stuff.  This is something people do  
> when they configure a shibboleth instance which occurs after the  
> build.  If your extension provides some special ARP functionality  
> than people need to be aware of this when they install your extension.

Amen.

> > 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$)?
>
> Currently I don't have support for attribute expansion.  We may  
> choose to expand a specific attribute, like SHIB_HOME, but there is  
> no way we're going to be able to create a mechanism that would  
> allow people to expand an arbitrary attribute to an arbitrary value  
> inside any given extension.

I think it does make sense to go ahead and do expansion on $SHIB_HOME 
$ (or whatever it ends up being).  Anything else is probably beyond  
the scope of what this thing needs to be doing.

> > (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.)
>
> Yeah, this is probably true.  I'd log this one as a separate bug.

Agreed.  Tom, can you enter a bugzilla?

-Walter