wireless package question...

I noticed a couple things about the wireless jar.

1.  It only includes the .dtd files, but fails to include the wml_1.1.xml 
file.  I assume that's an oversight, correct?

2.  The wml_1.1.dtd is referenced in build-default.properties, but doesn't 
actually exist in the source.  This is another oversight, correct?

2.  There is a voicexml.attr.properties file in 
org.enhydra.wireless.voicexml that isn't being added to the jar.  Should we 
be doing **/*.properties,**/*.dtd,**/*.xml to the build-default.properties 
file in order to make sure we include all needed support files?

3.  All the .dtd files and the wml_1.1.xml file are sitting in the default 
package.  Shouldn't these exist within their related packages?  For 
instance, shouldn't the wml related files go under org.enhydra.wireless.wml 
...and likewise for the other files?  Seems cleaner overall.

I can make these changes if I get the green light from the other committers.


On a somewhat related note, does it makes sense to have a target that 
creates a single xmlc-all.jar which contains the contents of...

wireless.jar
xerces.jar
xhtml.jar
xmlc.jar
xmlc-taskdef.jar

This is pretty simple to do.  I've got a quickly hacked together target (in 
the main build.xml file) which unjars each of these files to a directory 
and jars them into a single jar file.  It looks like this...

<target name="lib-all">
    <property name="libdir" location="./release/lib"/>
    <property name="unjardir" location="${libdir}/all"/>
    <delete dir="${unjardir}"/>
    <mkdir dir="${unjardir}"/>
    <unjar dest="${unjardir}">
      <fileset dir="${libdir}">
        <include name="wireless.jar" />
        <include name="xerces.jar" />
        <include name="xhtml.jar" />
        <include name="xmlc.jar" />
        <include name="xmlc-taskdef.jar" />
      </fileset>
    </unjar>
    <jar jarfile="${libdir}/xmlc-all.jar">
      <fileset dir="${unjardir}" />
    </jar>
  </target>

Creating an optional single xmlc-all.jar might make it simpler for people 
to use XMLC.  And given that everything proposed to be in the xmlc-all.jar 
falls under org.enhydra.* rather than including org.apache.* or any of the 
endorsed packages (see my previous email), there is no issue with namespace 
and version collisions with external packages ...which was the original 
impetus for splitting all this stuff up.  Now one would simply need...

xmlc-all.jar
bcel.jar
gnu-regexp.jar
jtidy.jar

One last thing.  Does it make sense to remove the com.lutris package 
entirely from the xmlc module?  At this point, I really don't think it 
matters.  If anyone using Enhydra uses XMLC-2.2, they'll still have the 
com.lutris stuff (if they still use it there).  If XMLC itself doesn't 
really use com.lutris.* (5 class in all of the XMLC CVS do, but they are 
excluded from the build, so they really don't count) itself, why should we 
keep it around?

Jake

Jake