Re: wireless package question...

Richard Kunze <[email protected]>
Newsgroups gmane.comp.java.enhydra.xmlc
Organization Tivano Software GmbH
Message-ID <[email protected]>
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, [email protected]
signature.asc (application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+yJuX86Aqb3OZfF4RAkdKAJ0UveQWj553RA7D+lZrvftveZHHbwCgkubu
+yHNh+WHfPUjtk2DPSYwU/c=
=sK54
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.