castor
  1. castor
  2. CASTOR-1802

Move org.exolab.castor.builder to org.castor.codegen package

    Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Trivial Trivial
    • Resolution: Unresolved
    • Affects Version/s: 1.1 M2
    • Fix Version/s: 1.4
    • Component/s: XML code generator
    • Labels:
      None
    • Number of attachments :
      0

      Description

      For backward compatibility we need to provide proxies for public classes at old org.exolab.castor.builder package. In addition anttask needs to be amended to use the new classes. We may also want to inform tool providers we know about this change.

        Activity

        Hide
        Ralf Joachim added a comment -

        The filename of castorbuilder.properties as well as the keys of the properties defined there should also be renamed.

        Show
        Ralf Joachim added a comment - The filename of castorbuilder.properties as well as the keys of the properties defined there should also be renamed.
        Hide
        Werner Guttmann added a comment -

        I am actually not convinced that this should be done at all. Basically we are forcing users to amend their (ideally) fully functional applications when upgrading to Castor 1.1. So far, we have always tried to provide backwards compatibility wherever possible. Why not in this case ?

        Show
        Werner Guttmann added a comment - I am actually not convinced that this should be done at all. Basically we are forcing users to amend their (ideally) fully functional applications when upgrading to Castor 1.1. So far, we have always tried to provide backwards compatibility wherever possible. Why not in this case ?
        Hide
        Edward Kuns added a comment -

        It shouldn't be too hard to support two "package names" for properties, if we choose to rename the default properties to a new package. At a time when someone decides to amend something, they can use global search & replace to rename existing properties. But I believe we all agree that we should be backwards compatible.

        Show
        Edward Kuns added a comment - It shouldn't be too hard to support two "package names" for properties, if we choose to rename the default properties to a new package. At a time when someone decides to amend something, they can use global search & replace to rename existing properties. But I believe we all agree that we should be backwards compatible.
        Hide
        Werner Guttmann added a comment -

        Yes please ... . It would make me happy, and I guess it would make users happy, too ...

        Show
        Werner Guttmann added a comment - Yes please ... . It would make me happy, and I guess it would make users happy, too ...
        Hide
        Werner Guttmann added a comment -

        I quite recently had a look at some 'external' dependencies, and somehow I am starting to think that such a move will have quite some impact on things like the Maven plug-in for Castor, the Eclipse plugin, etc. All these Castor-related tools somehow expose the XML code generator, but do not restrict themselves to using it as a simple dependency. E.g. the Maven plug-in sub-classes SourceGenerator, and makes use of a lot of other classes. Somehow I am getting less and less keen to change the package name(s) as suggested here and elsewhere.

        Can you please share your thoughts with me, whether it is a good idea to risk that we break external tools ?

        Show
        Werner Guttmann added a comment - I quite recently had a look at some 'external' dependencies, and somehow I am starting to think that such a move will have quite some impact on things like the Maven plug-in for Castor, the Eclipse plugin, etc. All these Castor-related tools somehow expose the XML code generator, but do not restrict themselves to using it as a simple dependency. E.g. the Maven plug-in sub-classes SourceGenerator, and makes use of a lot of other classes. Somehow I am getting less and less keen to change the package name(s) as suggested here and elsewhere. Can you please share your thoughts with me, whether it is a good idea to risk that we break external tools ?
        Hide
        Edward Kuns added a comment -

        Obviously, for external tools, if we do this change we'll need ot maintain backwards compatibility.

        Show
        Edward Kuns added a comment - Obviously, for external tools, if we do this change we'll need ot maintain backwards compatibility.
        Hide
        Ralf Joachim added a comment -

        How about leaving the classes in the old packages declared deprecated for one or two releases and apply fixes only to the classes in the new packages. This should give all external tools some time to move their code to use the new packages and with every patch that we apply to the new packages we improve the pressure to migrate.

        Show
        Ralf Joachim added a comment - How about leaving the classes in the old packages declared deprecated for one or two releases and apply fixes only to the classes in the new packages. This should give all external tools some time to move their code to use the new packages and with every patch that we apply to the new packages we improve the pressure to migrate.
        Hide
        Edward Kuns added a comment -

        Simpler than that, just have an empty class (marked deprecated) in the old location that is:

        public class OldClassName extends NewClassName {
        }

        and we'll exactly preserve function at the old class location.

        Show
        Edward Kuns added a comment - Simpler than that, just have an empty class (marked deprecated) in the old location that is: public class OldClassName extends NewClassName { } and we'll exactly preserve function at the old class location.
        Hide
        Werner Guttmann added a comment -

        Somehow I feel that the effort of creating a lot fo empty classes is not worth it. I don't know how you guys feel about this, but somehow I am in favour of closing this.

        Show
        Werner Guttmann added a comment - Somehow I feel that the effort of creating a lot fo empty classes is not worth it. I don't know how you guys feel about this, but somehow I am in favour of closing this.
        Hide
        Ralf Joachim added a comment -

        I still think that we should cleanup Castor's cluttered package hierarchy and as it seams right now this is the only way to do that.

        Show
        Ralf Joachim added a comment - I still think that we should cleanup Castor's cluttered package hierarchy and as it seams right now this is the only way to do that.
        Hide
        Edward Kuns added a comment -

        I am also in favor of still doing this. I'm almost caught up from my trip (how many weeks has it been?) and almost ready to pick up where I left off.

        Show
        Edward Kuns added a comment - I am also in favor of still doing this. I'm almost caught up from my trip (how many weeks has it been?) and almost ready to pick up where I left off.

          People

          • Assignee:
            Unassigned
            Reporter:
            Ralf Joachim
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: