At 04:32 PM 5/19/2003 +0200, you wrote:
> 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.
I'll leave that to you, if you don't mind. No rush.
> 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 :-)
Cool. But I won't move the files for now. I'll let you check
whether we use our own catalog handler and, if so, make the changes need
to load the files from the more appropriate locations. Otherwise,
if we don't use our own catalog handler, like you said, we should create
one and then load the files, again, from the appropriate
locations.
> > > 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?
This kind of breaks the consistency in all the build files. The
expectation is that the generated jar file will be the same name as the
module name. I'll leave it as-is for now. I think the name
xmlc-all-runtime.jar is clear enough for now.
> > > 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.
Are we sure that they aren't of some use after getting rid of the lutris
package references? They are actually quite minimal. I'll
leave them alone for now. They aren't built by default
anyway. If you look at them and think that they are definitely
useless even after removing the com.lutris package references, then go
ahead and remove them.
Jake
| 