castor
  1. castor
  2. CASTOR-597

Have SourceGenerator use a separate packages for class descriptor classes

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 0.9.5.2
    • Fix Version/s: 1.1 M1
    • Component/s: XML code generator
    • Labels:
      None
    • Environment:
      Operating System: All
      Platform: All
    • Bugzilla Id:
      1458
    • Number of attachments :
      2

      Description

      SourceGenerator should have an option to package both the subclasses and class
      description classes in seperate packages. This will make the documentation
      easier to navigate because it will be less cluttered.

      1. castor-597-first-patch.diff
        124 kB
        Edward Kuns
      2. castor-597-try2.diff
        134 kB
        Edward Kuns

        Activity

        Hide
        Edward Kuns added a comment -

        Ah, OK, I thought maybe the .castor.cdr was sufficient, but I agree that updating the CDR to also look in a specially-named subdirectory would be even better. This means, however, that the constant that names the subdirectory name should be owned by Castor-XML and not by Castor-XML-srcgen. It also means that we don't want people to have the ability to configure the name of this directory, so we should choose a name that people are unlikely to use for their own class files.

        The name "descriptors" might be Good Enough. A longer package name such as castordescriptors seems unnecessary – but much less likely to confict with a directory that someone wants to use for their own code package.

        Although finally, IMO, I think that generated code should usually be put into its own package and a separate package from code that is not generated, making code maintenance easier. Thus, as a general rule and best practice, I would recommend that anyone using the source generator choose a package that they are not using for other code for their generated code.

        Show
        Edward Kuns added a comment - Ah, OK, I thought maybe the .castor.cdr was sufficient, but I agree that updating the CDR to also look in a specially-named subdirectory would be even better. This means, however, that the constant that names the subdirectory name should be owned by Castor-XML and not by Castor-XML-srcgen. It also means that we don't want people to have the ability to configure the name of this directory, so we should choose a name that people are unlikely to use for their own class files. The name "descriptors" might be Good Enough. A longer package name such as castordescriptors seems unnecessary – but much less likely to confict with a directory that someone wants to use for their own code package. Although finally, IMO, I think that generated code should usually be put into its own package and a separate package from code that is not generated, making code maintenance easier. Thus, as a general rule and best practice, I would recommend that anyone using the source generator choose a package that they are not using for other code for their generated code.
        Hide
        Werner Guttmann added a comment -

        > This means, however, that the constant that names the subdirectory name should be
        > owned by Castor-XML and not by Castor-XML-srcgen.
        Yes.

        > It also means that we don't want people to have the ability to configure the name of this directory,
        Yes.

        > The name "descriptors" might be good enough
        Yes.

        And finally, yes once more to your approach towards 'best practice'.

        Show
        Werner Guttmann added a comment - > This means, however, that the constant that names the subdirectory name should be > owned by Castor-XML and not by Castor-XML-srcgen. Yes. > It also means that we don't want people to have the ability to configure the name of this directory, Yes. > The name "descriptors" might be good enough Yes. And finally, yes once more to your approach towards 'best practice'.
        Hide
        Edward Kuns added a comment -

        Attaching a 2nd patch which incorporates the structural changes made recently, moves some constants to XML, and handles missing .castor.cdr files gracefully by looking in the correct directory (after first looking in the previous location for these files, to handle older versions of Castor).

        Tested by making the test suite delete the .castor.cdr files and verified that the generated descriptors were still loaded.

        Show
        Edward Kuns added a comment - Attaching a 2nd patch which incorporates the structural changes made recently, moves some constants to XML, and handles missing .castor.cdr files gracefully by looking in the correct directory (after first looking in the previous location for these files, to handle older versions of Castor). Tested by making the test suite delete the .castor.cdr files and verified that the generated descriptors were still loaded.
        Hide
        Edward Kuns added a comment -

        Change delivered. Should I put something in the release notes about the new location of the descriptor files?

        Show
        Edward Kuns added a comment - Change delivered. Should I put something in the release notes about the new location of the descriptor files?
        Hide
        Werner Guttmann added a comment -

        Yes, please.

        Show
        Werner Guttmann added a comment - Yes, please.

          People

          • Assignee:
            Edward Kuns
            Reporter:
            Robert La Ferla
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: