Scan models in Subdirectories

[tobiasschaefer]

Currently, models are only found in the root resource directory. In future, the search should be recursive.

Currently, we're using PathMatchingResourcePatternResolver from Spring (probably comes via Camunda Dependency). We should switch that to io.micronaut.core.io.ResourceLoader

See also https://stackoverflow.com/questions/53370135/is-there-an-equivalent-for-springs-resource-in-micronaut

[tobiasschaefer]

This has been implemented on master. Unfortunately, we need the CLI dependency but at least it works for now.

[tobiasschaefer]

Reopening because changes needed to be reverted on master because this did not work if started with "java -jar", see commit b5e5eac

[tobiasschaefer]

Note: it must be possible to solve this with ahead of time (AOT) compilation, i.e. we resolve the process models at compilation time, not runtime.

[tobiasschaefer]

Tobias wrote in Gitter:

Hi all,

on application startup I need the paths of all *.xyz files found recursively in the resources of the application.

How can I determine all the *.xyz files? Since this information is available at compile time it would be nice to be able to generate that information during compilation to prevent a classpath scan at runtime. Any hints?

Hint from Graeme Rocher

the way to do this is with a TypeElementVisitor that visits an annotation on a type (say @ResourceScan) then scans for the files locally then calls annotate(..) to dynamically annotate teh class with the correct value that can be read at runtime

see also
https://www.slideshare.net/graemerocher/micronaut-deep-dive-devoxx-belgium-2019 (Slide 36)
https://www.slideshare.net/graemerocher/micronaut-and-the-power-of-ahead-of-time-compilation-devnexus-2019 (Slide 9 to 16)

[StephenOTT]

Have you solved how to serialize the various camunda caching to compile it? A lot of the internal classes are only partially Serializable: a lot of inconsistencies.

There were also some issues we ran into around aot compilation: things like ID generation of many of the values, various caches (DBCache, Deployment Cache, etc) that were not designed for pre-comp

[tobiasschaefer]

@StephenOTT : This issue here is only about resolving the paths of the models in the classpath. The AOT of the process models itself is part of #85 .

Regarding #85: I'm actually not thinking of serializing the process model definition instances but transforming the process models into a fluent API using org.camunda.bpm.model.bpmn.Bpmn.createProcess(...)

[StephenOTT]

Okay. Note that the fluent API does not support all aspects BPMN. So as a result you need to manually generate many of the objects at a low level of the API. (Again went down this path as well for other use cases)

[Hayvon]

GraalVM and Micronaut Data also uses TypeElementVisitor

See: https://github.com/micronaut-projects/micronaut-core/blob/69ec24c34aebc244209f4e2ced47af694a4d05a1/graal/src/main/java/io/micronaut/graal/reflect/GraalTypeElementVisitor.java#L323

See: https://github.com/micronaut-projects/micronaut-data/blob/master/data-processor/src/main/java/io/micronaut/data/processor/visitors/RepositoryTypeElementVisitor.java#L381

[Hayvon]

Current version can be found under: https://github.com/Hayvon/micronaut-camunda-bpm/tree/processModelsAoT

Current ToDos:

• The @ResourceScan Annoation is still set in the Example
• GradleDaemon bug: GradleDaemon has to be killed manually after code execution on Windows
    Reproduce: ./gradlew clean run --> CRTL + C --> ./gradlew clean run
    Fix: ./gradlew clean run --no-daemon

[tobiasschaefer]

A GraalVM feature for Flyway that calculates the migration to apply at compile time:

• https://github.com/micronaut-projects/micronaut-flyway/blob/master/src/main/docs/guide/graalvm.adoc
• https://github.com/micronaut-projects/micronaut-flyway/blob/master/flyway/src/main/java/io/micronaut/flyway/graalvm/FlywayFeature.java

[tobiasschaefer]

Scanning recursively is not very resource efficient - instead the locations can now be configured which is the same as for micronaut-flyway.