Shibboleth Developers

[Brent Putman <>]

This change broke the build entirely for me.  I was getting an Ant error 
that the "for" task that you are using in the extension-build.xml was 
unknown.  After investigating, I discovered that in the 
net/sf/antcontrib/antcontrib.properties file in ant-contrib.jar, the For 
task is commented out. 

# Tasks Requiring Ant 1.6 or higher
#for=net.sf.antcontrib.logic.For
math=net.sf.antcontrib.math.MathTask

Uncommenting it makes the build work after that.  This is also the case 
in the latest jar downloaded from here:
http://ant-contrib.sourceforge.net/

Is this what you did or is there some better way to handle?

After fixing this, however, an "ant clean-all" still results in an error 
when it calls the clean-ext target:

clean-ext:

BUILD FAILED
/opt/src/shib-HEAD/java/custom/extension-build.xml:185: 
/opt/src/shib-HEAD/java/${exts.dir} not found.


--Brent



Chad La Joie wrote:

> I just checked this in to head, so when the public repository is 
> sync'ed with the commiter's repo people should be able to try this out.
>
> Chad La Joie wrote:
>
> > There has been discussion off list about how to proceed with custom
> > extensions (name mappers, protocol handlers, etc) to Shibboleth, those
> > things that currently go in to the "custom" directory in the Shib IdP/SP
> > code base.  Here is my proposition for a more formal and flexible way to
> > deal with these custom extension.
> >
> > 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
> >
> > 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).  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.
> >
> > When the IdP or SP was built it would compile each extension in turn
> > (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.
> >
> > 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.
> >
> > Thoughts and comments?