castor

Clean up Castor XML; remove unnecessary replacements of Java 1.2 classes

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 1.1 M1
  • Component/s: XML
  • Labels:
    None
  • Number of attachments :
    1

Description

I would like to do some cleanup tasks. I have identified two to start with. What do you think?

1) Move org/exolab/castor/xml/gui/* into a new directory org/exolab/castor/xml/tools/gui/

Rational: That GUI is not a GUI for Castor. It's a tool not directly related to Castor.

2) Remove the classes org.exolab.castor.util.List and org.exolab.castor.util.Iterator and replace all usage of those classes with the J2 equivalents.

Rational: We no longer support anything before 1.3. List, according to its JavaDoc, is not complete yet. Rather than have to maintain copies of the official Java code, let's get rid of the copies and use the official JDK methods.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ralf Joachim added a comment -

to 2) I expect this classes not to be used by anybody anymore so we can instantly remove them without previous deprecation.

to 1) I guess you are refering to org.exolab.castor.gui which is a tool to execute OQL queries using JDO and does not belong to XML. I agree with you that this package is way not ideal but I still have not a good idea where this should be moved with regards of http://docs.codehaus.org/display/CASTOR/Subprojects . Having said that I don't know if somebody is using that gui tool and relate on its current package name. We therefore sould move things only once when we definitly know where to move it.

Show
Ralf Joachim added a comment - to 2) I expect this classes not to be used by anybody anymore so we can instantly remove them without previous deprecation. to 1) I guess you are refering to org.exolab.castor.gui which is a tool to execute OQL queries using JDO and does not belong to XML. I agree with you that this package is way not ideal but I still have not a good idea where this should be moved with regards of http://docs.codehaus.org/display/CASTOR/Subprojects . Having said that I don't know if somebody is using that gui tool and relate on its current package name. We therefore sould move things only once when we definitly know where to move it.
Hide
Permalink
Edward Kuns added a comment -

1) Good point regarding people already using this via the current package. I didn't recognize that this tool doesn't even belong to XML. Once we decide where to move it, we can always create a deprecated proxy class in its current location so that there'll be a time where people can use the old or new name but the old one will be deprecated and can print a useful warning.

Show
Edward Kuns added a comment - 1) Good point regarding people already using this via the current package. I didn't recognize that this tool doesn't even belong to XML. Once we decide where to move it, we can always create a deprecated proxy class in its current location so that there'll be a time where people can use the old or new name but the old one will be deprecated and can print a useful warning.
Hide
Permalink
Werner Guttmann added a comment -

One option re: 2) would be to move it to a sub-project (resulting into a new and separate deployment unit), and maintain the 'wrong' package name. If that is not being liked by us, a small (and deprecated) proxy class would be okay for me.

Re: 1), I think we have to make sure that Castor does not pass any of these classes to a client program using Castor. Without having had a look myself, I think (hope) this will not be the case .. .

Show
Werner Guttmann added a comment - One option re: 2) would be to move it to a sub-project (resulting into a new and separate deployment unit), and maintain the 'wrong' package name. If that is not being liked by us, a small (and deprecated) proxy class would be okay for me. Re: 1), I think we have to make sure that Castor does not pass any of these classes to a client program using Castor. Without having had a look myself, I think (hope) this will not be the case .. .
Hide
Permalink
Edward Kuns added a comment -

I looked at four types and was able to prove that none of those types escaped our code. I removed four types from xml.util – one which was not used anywhere and three that were "copies" of java.util classes.

Show
Edward Kuns added a comment - I looked at four types and was able to prove that none of those types escaped our code. I removed four types from xml.util – one which was not used anywhere and three that were "copies" of java.util classes.
Hide
Permalink
Edward Kuns added a comment -

XML & JDO test frameworks both complete happily. (I still get the test #2 failure in JDO under Linux, but that's not related to this change.)

Show
Edward Kuns added a comment - XML & JDO test frameworks both complete happily. (I still get the test #2 failure in JDO under Linux, but that's not related to this change.)
Hide
Permalink
Edward Kuns added a comment -

This was a little bit more complicated than I thought, but all test cases pass. (More complicated than I thought mostly due to subclipse getting confused even though command-line SVN commands were fine.)

Show
Edward Kuns added a comment - This was a little bit more complicated than I thought, but all test cases pass. (More complicated than I thought mostly due to subclipse getting confused even though command-line SVN commands were fine.)

People

  • Assignee:
    Edward Kuns
    Reporter:
    Edward Kuns
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: