GenerateDatasetsXml Improvements Overall Tracking

[ChrisJohnNOAA]

This is a tracking bug for the improvements we want to make to GenerateDatasetsXml:

• Provide better support for adding new dataset types to GenerateDatasetsXml
• JSON input to GenerateDatasetsXML to provide better programmatic interaction
• Improve the xml that is generated (port improvements from ERDDAP CMS and other improvements)
• Output each dataset as individual xml file (option specified by the user whether they want a file saved or the contents in the terminal)
• Separate xml generation from creating a dataobject to represent the dataset (this is to assist with embedding the logic elsewhere)
• Make sure the tool is easy to use and accessible to admins. Some ideas discussed: make the command line tool more easily accessible (maybe runnable outside of the Tomcat install environment), add a page in a running ERDDAP that allows generating datasets xml snippets directly from ERDDAP (and if sufficient security in place, allow admins to update the running datasets.xml from the page).

Note that sub issues do not yet exist for all parts of this.

[rohan-019]

Hi @ChrisJohnNOAA,

I’ve been reviewing #418 along with #206 (reflection-based EDD discovery).

From what I understand ERDDAP runtime can now dynamically discover EDD subclasses using ClassGraph, but GenerateDatasetsXml still relies on manual dataset type handling.

Would the preferred direction be to reuse the same reflection registry mechanism from #206 inside GenerateDatasetsXml, or should the script maintain a lighter-weight discovery approach tailored for CLI use?

I’m particularly interested in understanding whether long-term maintainability should prioritize sharing the same discovery logic between runtime and XML generation

Thanks

[ChrisJohnNOAA]

Hi @rohan-019 ,

In case your interest here is for GSoC projects, the selections for organizations for GSoC have not happened yet. It's recommended to wait until we know we will be a selected org for GSoC to work on the projects. If you're interested in contributing to ERDDAP not through GSoC we always welcome contributions, I just want to make sure expectations are set appropriately.

I think the reflection registry mechanism is the best path for this, for the same reasons we picked it in #206. Most likely we can extend the existing annotation or add an additional annotation to cover what we need for this. Additionally for long term maintainability it's better if systems designed for similar purposes in the project can work the same way.

[rohan-019]

Hi @rohan-019 ,

In case your interest here is for GSoC projects, the selections for organizations for GSoC have not happened yet. It's recommended to wait until we know we will be a selected org for GSoC to work on the projects. If you're interested in contributing to ERDDAP not through GSoC we always welcome contributions, I just want to make sure expectations are set appropriately.

I think the reflection registry mechanism is the best path for this, for the same reasons we picked it in #206. Most likely we can extend the existing annotation or add an additional annotation to cover what we need for this. Additionally for long term maintainability it's better if systems designed for similar purposes in the project can work the same way.

Thanks for the clarification.

I’ll continue exploring the reflection mechanism and GenerateDatasetsXml implementation. In parallel, I’d like to contribute in other parts of the codebase to build familiarity with ERDDAP’s architecture.

If there are areas where help is particularly needed, I’d appreciate any pointers.