Core: @OpenmrsProfile to filter for modules that are absent

Development
,
#1

Hi all,

We could find some use with having @OpenmrsProfile being able to filter for modules that are absent. Is there a way to specify this currently? Looking at OpenmrsProfileExcludeFilter (here) I am under the impression that there is no way to currently do that.

If I’m correct, could this be an acceptable syntax for such cases?

@OpenmrsProfile(modules = {"moduleId:_"})

Could you let me know if this is a valid/worthy idea?

Cc @dkayiwa, @darius, @raff, @wyclif

How to segregate imports of module being 'aware of' away from Spring wiring?
How to segregate imports of module being 'aware of' away from Spring wiring?
#2

@mksd do you currently have a use case for that?

#3

Yes it is a consequence of attempting a full leverage of the ‘aware of’ config directive. When doing so one might not so much be interested in filtering for ranges of versions of a module, but rather to know whether a module is present (with any version) or missing.

Our specific use case is about AH’s awareness of Ext I18N.

  • If Ext I18N is present it should provide an implementation to one of AH’s interfaces. @OpenmrsProfile(modules = {"exti18n:*"})

  • If Ext I18N is absent then AH itself should provide a default implementation to its interface. @OpenmrsProfile(modules = {"exti18n:_"})

The above config could be put in place, with @Autowired-annotated instances of AH’s interface, that would work both at runtime and within context-sensitive tests. See also ‘Core: enabling context-sensitive tests to start modules’.

Cc @mogoodrich

#4

Sounds worthwhile to me.

An alternative syntax could be

@OpenmrsProfile(modules = {"!exti18n"})

(I haven’t checked how this fits with the other existing syntax; take this as an uninformed suggestion.)

1 Like
#5

I like your syntax idea, very straightforward. And it will be straightforward enough parsing strings starting with '!'.

#6

Just created TRUNK-5213: ‘Load Spring resources conditionally based on missing module(s)’.

#7

Ok this is now done and merged thanks to @dkayiwa. See TRUNK-5213 and TRUNK-5216.

Would everyone be ok to backport this down to 1.10.x? @darius, @mogoodrich, @mseaton, @angshuonline

For reference, I stated in TRUNK-5213:

#8

@mksd and @dkayiwa - good work. No objection from me on backporting.

#9

Fine with me as well @mksd… thanks to you and @dkayiwa for all your work on this, as I know it has mushroomed!

Take care, Mark