Re: wireless package question...

Hi Richard,

See comments inline below...

At 10:53 AM 5/19/2003 +0200, you wrote:
> 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

Weird.  Well, if that's the way they distribute it, I guess people
will be looking for that file name so maybe it doesn't make much sense to
change the name.  However, it definitely needs inclusion in the .jar
file.  I've got that happening in my local tree and will commit that
change.

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

Hmm... not sure that's quite necessary, otherwise we might have stuff
like make files getting into the jars.  I think, for the most part,
.properties, .xml, and .dtd covers it.  If we find other cases,
we'll add them.  We want to be inclusive, but not so much that
unrelated stuff gets let into the jars.

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

The XHTML dtd's exist under their respective package, though (
org.enhydra.xml.xhtml ).  Personally I think this is cleaner....and
aren't these DTD's generally used internally anyway for entity
resolution?  That is, if one references the public location of the
DTD, the internal XMLC classes look for it locally in some
location?  If that's the case, then it doesn't matter that we have
to know the package.  We know it anyway, why not use it?  Just
think if all projects put their xml and dtd files in the default
package.  The default package would be quite a mess of these
files.  The files should be in their proper namespaces.  If you
still disagree, I won't change anything, but hopefully I've made a
compelling argument that will convince you to change your mind.  Did
I?

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

Agreed.  There is already an xmlc-taskdef.jar, so no extra jar
there.  Just the xmlc-runtime.jar will be new.  Actually, might
want to say "xmlc-all-runtime.jar".  I say this because on
the face of it, if one see's "xmlc.jar' and then see's
"xmlc-runtime.jar" one might think they need both jars. 
Calling it "xmlc-all-runtime.jar" makes it more clear that it
is an alternative to xmlc.jar (+other related xmlc jars).

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

Cool.  Should I also remove any classes (5 total) that use the
com.lutris package in the source?  There are 4 testcases and 1
normal java file that import com.lutris packages.  They are
currently excluded from the build.  Should they  be left in
place for reference or removed?

Jake

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