On Monday 19 May 2003 15:05, Jacob Kjome wrote:
> 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.
I'd suspect most people won't go looking for it under any name, they just
expect XMLC to find the appropriate DTD :-)
Any way, the file defintely needs to be included. The name isn't that
important, so go ahead and commit.
> > > 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.
Good point, agreed.
> > > 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....
Yes, it's definitely 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?
I have to admit, I don't know out of hand if XMLC installs its own catalog
handler. Have to look at the sources, but can't do that today (I'm at a
customers right now, and don't have the sources here).
On the other hand, if we don't already install our own catalog handler for
well-known and widely used DTDs, we probably should do so.
> 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?
Yes :-)
> > > 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).
Sounds good. Maybe rename xmlc.jar to xmlc-core.jar at the same time?
> > > 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?
Remove them - they are still in CVS for reference.
--
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
pgpwcL4gs1AHG.pgp
Description: signature
|
