Re: wireless package question...

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