Shibboleth Developers

[Tom Scavo <>]

Chad, before I get too deep into this, do you agree that the path
order in extension-build.xml is faulty?

On 8/22/05, Tom Scavo 
<>
 wrote:
> On 8/22/05, Tom Scavo 
> <>
>  wrote:
> >
> > More importantly, class
> > directories need to be searched before lib directories, right?  This
> > needs to be fixed in the buildfiles, I think.
> 
> This is the current path from extension-build.xml:
> 
>     <path id="ext.path">
>         <!-- Shibboleth Libraries -->
>         <path refid="build.path" />
> 
>         <!-- Shibboleth Classes -->
>         <pathelement location="${build}" />
> 
>         <!-- Extension libraries -->
>         <fileset dir="${ext.lib}">
>             <include name="**/*.jar" />
>         </fileset>
> 
>         <!-- Extension classes -->
>         <pathelement location="${ext.classes}" />
> 
>         <!-- Extension test classes -->
>         <pathelement location="${ext.test.classes}" />
>     </path>
> 
> If order of path elments is important (and I think it is), this is
> wrong.  The path should be
> 
>     <path id="ext.path">
>         <!-- Shibboleth Classes and Libraries -->
>         <path refid="build.path" />
> 
>         <!-- Extension test classes -->
>         <pathelement location="${ext.test.classes}" />
> 
>         <!-- Extension classes -->
>         <pathelement location="${ext.classes}" />
> 
>         <!-- Extension libraries -->
>         <fileset dir="${ext.lib}">
>             <include name="**/*.jar" />
>         </fileset>
>     </path>
> 
> The explicit reference to ${build} is redundant and therefore not
> needed.  More importantly, extension classes need to be searched
> before extension JARs.
> 
> Also, since the path needs to be modified anyway, I'll include the
> following nit.  The above path does triple duty since it's used for
> both compile operations and the unit testing,  but not all path
> elements are needed for all three operations.  Doesn't matter too
> much, I guess, but the multiple paths defined in build.xml are perhaps
> a better way of handling it.
> 
> Tom
>