Shibboleth Developers

[Chad La Joie <>]

Tom Scavo wrote:
> - Targets clean-install and install.idp.filesystem in build.xml invoke the 
> task
>   <delete dir="${idp.home}/etc" />
> The latter is benign and can be safely removed but the delete task in
> clean-install is a potentially serious problem.

Walter is probably better able to address this one, but if I ran 
clean-install I'd expect it to clean out everything is installed.  If I 
just wanted to clean out the built stuff (classes, generated jars, etc) 
I'd use the clean-build target.  Maybe this just needs some documentation.

> - Target ext-build-init in extension-build.xml emits a message re
> default-build.properties, which doesn't exist.
>
> - Target ext-copy-src-conf in extension-build.xml emits a message re
> the 'etc' directory, which is false.

Yep, this was left over from something else I was doing with the file. 
I'll change that.

> - Invoking ext-compile (independent of ext-build) in
> extension-build.xml produces no class files since ext-compile does not
> depend on ext-build-init.
>
> - Target ext-copy-libs in extension-build.xml depends on ext-compile
> instead of ext-build-init.
>
> - Target ext-copy-webpages in extension-build.xml depends on
> ext-compile instead of ext-build-init.
>
> - Invoking ext-gen-docs (independent of ext-build) in
> extension-build.xml produces no javadoc files since ext-gen-docs does
> not depend on ext-build-init.
>
> - Invoking ext-package (independent of ext-build) in
> extension-build.xml produces an empty JAR file since ext-package does
> not depend on both ext-compile and ext-copy-src-conf.

These tasks can not be invoked individually, and none of the tasks are 
meant to be executed by anything other than the main build file.  If you 
attempt to do so you'll need to make sure a whole lot of environmental 
stuff is set up correctly.  Failure to do so will cause the behavior 
you're seeing.

> - Target clean-javadocs in build.xml should clean extension javadocs as well.

Yep, it should.

> - Reverse the order of sections 2.1 and 2.2 in README.txt.
>
> - Add the following nested element to the <javadoc> element in
> extension-build.xml:
>   <link href="http://java.sun.com/j2se/1.5.0/docs/api/"/>
>   
> - Add attribute deprecation="true" to the <javac> element in
> extension-build.xml.
>
> - There's a reference to "build-exts" (which doesn't exist) in a
> comment in extension-build.xml.
>
> - The comment prior to ext-package in extension-build.xml says
> parameter ext.build.function is required, which is false.

Yep to all of these.

> - The location of the javadocs is nonstandard with respect to the rest
> of the project so the following workaround is in place in the GridShib
> extension's build.properties file:
>   gridshib.doc=doc
>   gridshib.javadocs=${gridshib.doc}/api
>   ext.docs=${ext.root}/${gridshib.javadocs}

Yeah, this should probably be changed.

> - The GridShib extension is already using directory dist/ for a
> different purpose (similar to the OpenSAML project) so the following
> workaround is in place in the extension's build.properties file:
>   gridshib.build=build
>   ext.dist=${ext.root}/${gridshib.build}

Yep, this should probably be changed too.

As a side note, while you can override properties in the extension's 
build file like you're doing, it's not a supported or documented 
feature.  So, do this at your own risk.

> - Mention the throwaway directories ext.dist, ext.classes, and
> ext.docs in README.txt so extension developers are aware of the
> potential conflicts.

Not sure this makes sense.  The README file tells you everything you can 
touch.  Implied in that is the "if it's not permitted it's denied" rule. 
 I guess I can put a line to the effect in there.

> - Property ext.name is used for dual purposes.  In almost all cases,
> it's value should be lowercase (as in "gridshib") but where it's used
> in the <javadoc> element, it should be mixed case ("GridShib").  How
> can this be reconciled?

I'm don't really see a problem here.  Case is irrelevant to anything 
that matters.  All lower case works fine in the java docs, mixed case 
works fine in naming the jar.  For example, I use mixed case in an 
extension that I wrote.  The only thing you probably need to be careful 
of is spaces in the name.  Java on windows had issues with that for a 
long time (I think it's fixed though).

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