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

[teleivo (Ivo Ulrich)]

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 ?

[dkayiwa (Daniel Kayiwa)]

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

[cintiadr (Cintia Del Rio)]

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.

[cintiadr (Cintia Del Rio)]

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.

[dkayiwa (Daniel Kayiwa)]

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

So i guess this was just not uploaded.

[cintiadr (Cintia Del Rio)]

It’s pretty trivial to add, though.

[teleivo (Ivo Ulrich)]

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.

[teleivo (Ivo Ulrich)]

@dkayiwa

So i guess this was just not uploaded.

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

[dkayiwa (Daniel Kayiwa)]

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.

[teleivo (Ivo Ulrich)]

@dkayiwa

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.

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

[burke (Burke Mamlin)]

@dkayiwa

My guess is that they were manually created

I would guess the same.

@teleivo

Is there a repo with them? I wonder why they are not in openmrs-core repo.

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).

@teleivo

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

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.

[teleivo (Ivo Ulrich)]

@burke

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

Module Config File - Documentation - OpenMRS Wiki 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?

@burke

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.

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

My (longer term) plan is:

• test ModuleFileParser (done and merged )
• refactor to make it unit testable (I am almost done , 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.

[teleivo (Ivo Ulrich)]

@teleivo

My (longer term) plan is:

1. test ModuleFileParser (done and merged )
2. refactor to make it unit testable (I am almost done , and will propose the changes before merging)
3. 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 [TRUNK-5388] - OpenMRS Issues with my rational and a pull request so anyone can review what I have in mind.

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

[darius (Darius Jazayeri)]

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?

[teleivo (Ivo Ulrich)]

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

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?

[burke (Burke Mamlin)]

@teleivo

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

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

[darius (Darius Jazayeri)]

@teleivo

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?

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.

[teleivo (Ivo Ulrich)]

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

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

@darius

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.

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.

[darius (Darius Jazayeri)]

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