where can I find config.xml dtds on esource.openmrs.org?

Hi,

https://wiki.openmrs.org/display/docs/Module+Config+File and the openmrs-core javadoc of the ModuleFileParser point to URLs like

http://resources.openmrs.org/doctype/config-1.6.dtd

which does not exist.

Is this maybe linked to docs and resources migration ?

That looks like it. @cintiadr will be the referee here. :smile:

Hum, I don’t think so.

Is it possible the file never existed?

I mean, it’s trivial to upload OR to have a build to upload it, but I took all doctypes at the time.

This is where I mentioned which ones I was thinking about deleting: Can I delete these files from resources?

But I was told to keep doctypes. If you strongly believe it was there already, I can recover the old backups.

It looks like the last upload was this: https://issues.openmrs.org/browse/ITSM-2913

So i guess this was just not uploaded.

It’s pretty trivial to add, though.

thanks a lot @cintiadr!

Does anyone know how they are created/maintained? Is there a repo with them? I wonder why they are not in openmrs-core repo.

Do you have the file or know where we can get it from? I would like to use it :smile:

My guess is that they were manually created from the most recent one, and then added what had changed. @wyclif and @raff can correct me because they have ever done it. :slight_smile:

@wyclif or @raff can you please help me find the config-1.6.dtd file :slight_smile:

I would guess the same.

These predated our move to GitHub. I agree that it would make sense to manage them within openmrs-core (they’d still need to be hosted at resources.openmrs.org/doctypes).

If we can identify the differences from 1.5 to 1.6 in config.xml, I can create the DTD if needed.

BTW… the existing DTDs appear to have undeclared elements (for example, in 1.4 and I think 1.5 is the same, I see these as undeclared: class, point, mappingFiles, allow, init, signatures, filter-class, filter-name, servlet-name, url-pattern, defaultValue, description, property, param-name, param-value, file, lang, activator, author, id, name, package, require_database_version, require_version, updateURL, version, servlet-class). We also have a pretty ugly history of naming conventions combining under_score, hyphen-ated, and camelCase. :confused:

1 Like

https://wiki.openmrs.org/display/docs/Module+Config+File says that the difference is:

  • Added conditionalResources element
  • Supports multiple version ranges for version e.g. “1.8.5 - 1.9, 1.9.8”

not sure if this is enough/if we can be certain that that’s the only thing that changed. What do you think?

yes, thats true I also noticed that our DTDs are actually not valid.

My (longer term) plan is:

  • test ModuleFileParser (done and merged :smile:)
  • refactor to make it unit testable (I am almost done :slightly_smiling_face: , and will propose the changes before merging)
  • put the DTDs under version control somewhere to improve the upgrade process of the config xml DTD versions
  • (maybe, if wanted) let the ModuleFileParser use the DTD to validate the config.xml, this should reduce our code in the ModuleFileParser and give module devs better output of whats wrong.

I have a proposal for refactoring of the ModuleFileParser at https://issues.openmrs.org/browse/TRUNK-5388 with my rational and a pull request so anyone can review what I have in mind.

would be great to get opinions :slight_smile: ping for example @darius @dkayiwa @mksd

I skimmed the ticket and it sounds fine.

In the bigger picture, I believe that @burke has always wanted us to refactor/redesign such that we have a proper “Module Service”. How would your proposed refactoring play into this?

I have to hear the specifics from @burke on what this service would exactly do, and am open to work on it :slight_smile:

But I am sure the ModuleFileParser could easily be used by the service after this refactoring, since my goal is that it doesnt hold on to any file and has explicit (mock’able) dependencies.

One aspect I could use your input is the parse(InputStream), which uses the implementation that was already in place. It copies the given InputStream to a tmp folder using javas File.createTempFile("moduleUpgrade", ".omod"). Can you clarify why we dont store it somewhere more permanent?

There’s a high level notion of Module Service in TRUNK-1863.

1 Like

I never looked at that code even when it was being written, so this is wild speculation on my part due to the variable name: maybe it’s because this code comes from when a file is being uploaded to the server via the admin UI’s upload a module, and we need to verify that it can be parsed and is valid, before actually copying it to the modules folder.

I am interested and will gather some ideas as I wanted to move my way up the stack from parsing, loading a module anyway :slight_smile: And am a fan of removing static methods :wink:

I believe my current refactoring is in support of this bigger picture.

makes sense!

Do you think I should get more input from some other devs on this refactoring (before merging)? If so could you please cc them here.

I don’t think you need any more input on the current refactoring, assuming that no public APIs or behaviors change…