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