Re: wireless package question...

On Monday 19 May 2003 08:05, Jacob Kjome wrote:
> 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?

Both oversights are related :-) wml_1.1.xml is the DTD file for WML (no idea 
why they distribute it with a .xml extension), so it should probably be 
renamed to wml_1.1.dtd

> 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?

Yes, probably. Maybe even do an include for "**" and specifically exclude 
"**/*.java"?

> 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.

No, they are in the default package by design. That way, you can simply do a 
getResourceAsStream("/whatever.dtd") to read it, which comes in handy when 
the whatever is defined by e.g. the system identifier for a DTD that is read 
from an input file.

If you put it into the related package, you have to know the package name in 
order to access the file correctly.

> 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

I'm not really sure about the taskdefs as they are not needed at runtime. 
Other than that, great idea. So, I propose two jars, xmlc-runtime.jar 
containing everything save the taskdefs and a seperate xmlc-taskdef.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?

Go ahead and drop it. the com.lutris stuff is left over from way back when :-)

-- 
Richard Kunze 

[ t]ivano Software, Bahnhofstr. 18, 63263 Neu-Isenburg
Tel.: +49 6102 80 99 07 - 0, Fax.: +49 6102 80 99 07 - 1
http://www.tivano.de, kunze@xxxxxxxxx

pgpu52iyzTJRS.pgp
Description: signature