Shibboleth Developers

[Chad La Joie <>]

Yeah, this was my mistake  The for task, as the comment says, is 
commented out because it requires ant 1.6 or higher.  We are using 1.6 
so it's safe to use the task, I just forgot to check in the jar that has 
that task turned on.

The bugs in the build itself are also fixed.

Brent Putman wrote:
> 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?

--
Chad La Joie             315Q St. Mary's Hall
Project Sentinel         202.687.0124