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