Shibboleth Developers

[Scott Cantor <>]

> Summary: The current approach of separate Origin and Target 
> distributions raises a problem for Java where there are 
> classes that should be reused at both ends. Maintaining two 
> copies of common source is not a good idea. An alternate 
> package distributes a single library of all Java code with 
> separate configurations for Origin and Target, or a combined 
> deployment for testing, development, or where both functions 
> are required. 

Note that cvs is divided into c/ and java/, not origin and target. It's
merely that this corresponded to origin and target, not that we necessarily
intended separateness. OTOH, with a few exceptions, it's not been the case
that people wanted both either...

> In the current Java Origin, many classes that would be shared 
> between the origin and target are in the 
> edu.internet2.middleware.shibboleth.common package [which I 
> will abbreviate "edu.i2.mid.shib..." from now on]. However, 
> in the current code, "common" only means "shared by the HS 
> and AA". A few Origin-only classes are in common. I can:
> 
> 1) Leave this, and put corresponding target-only classes in 
> the same package name.

I don't think this would be that big a deal.

> 2) Leave this, but put target-only classes in 
> edu.i2.mid.shib.target. Then the "common" package would 
> contain some truly common classes and some origin classes, 
> but all target classes would have been segregated.

This option was also somewhat in my mind when I picked strings to use for
class names to name plugins (obviously C++ doesn't use string-based
introspection so I was just trying to anticipate some naming conventions.

> 3) Move the origin-only classes to a new 
> edu.i2.mid.shib.origin package. Then common would be common 
> to all, origin would be origin-only, and target would be target-only. 

I'll let Walter decide this. I doubt it would be that big a change to do
this.

> This assumes that the other packages that are not explicitly 
> AA, HS, or WAYF related (log, metadata, utils) can be left as is. 

At a minimum, I know metadata, trust, revocation, and credentials are
functional areas that will need to be shared/common.

As far as packaging goes, I'm sure ant has enough tricks up its sleeve to do
any of the options you suggested. I do think it's probably a good idea to
maybe separate the classes into a jar and just leave the warfile(s) with
less of that stuff and just the configuration, JSPs, etc.

Returning to my original comment, probably the question is whether the
average person would want both subsystems. In any given deployment, they
would not, so having a single warfile is not a good way to go, while having
a single distribution might still be, since it's not *that* big anyway.

-- Scott