Page History
Table of Contents |
---|
Jira | ||||||
---|---|---|---|---|---|---|
|
...
- Use Resources API
- Split scripts vs. classes (scripts stay in current workspace and functionality for executing scripts stay stays in groovy the Groovy module. Support for classes will be removed from Groovy module and placed in resources workspace)
- Maintain support for scripts in JCR > scripts
...
Apparently such classes do appear show up in the Resources App. I created a Groovy script in a package classpath.scripts
in Eclipse under src/main/resources
...
The Groovy module replaces Magnolia's DefaultClassFactory
with its GroovyClassFactory
which internally delegates loading the Groovy source files to MgnlGroovyResourceLoader#loadGroovySource(..).
The latter is therefore called very early during Magnolia startup (it is indeed called internally by the GroovyClassLoader
) when ResourceOrigin
(the entry point for clients of the Resources API) is not ready yet. That would cause a ComponentNotFoundException
when NoSuchComponentException
when trying to get hold of ResourceOrigin
via Components.getComponent(..)
.
Solution in PoC consists in using a ResourceOriginProvider
and skip Groovy resources loading as long as the provider is null. This seems to be safe as during Magnolia's early startup phase there are no Groovy scripts/classes to be instantiated and the loading of Java classes needed by Magnolia is delegated to the parent class loader.
...
- module-names may contain dashes but Java does not allow having a package name with dashes. Scripts (which are eventually compiled as Java classes) need to declare a valid, unique package to compile and for this whole feature to work.
- if module name is in the package name dash ( - ) needs to be replaced (by underscore? or use some other convention)
- next to the templates (convenient to edit, but hard to specify correct package name) vs. special folder (would make it easier to have package name w/o module name in it
- ideally would favor no special tricks
As far as I could see, having a special folder in the light module structure, e.g. one called groovy,
would not solve the issue because
...
- adapt Groovy module tests to use Resources API
- migrate enabled Groovy sources (non script ones) from the
scripts
to theresources
workspace. Groovy source is found in a property calledtext
which is also available for resources. - remove the
script
andenabled
fields at /modules/groovy/apps/groovy/subApps/detail/editor/form/tabs/script/fields and their values in the remaining scripts in thescripts
workspace. - move/adapt Groovy validation to Groovy files in
resources
, e.g. when created in the app or hot fixed - still re validation, how to signal an invalid Groovy file (syntax, package matching folder structure under light module) Groovy file when when working on the file system?
- in dev mode observe Groovy files via Resources API and validate on resource added/changed, throwing an exception in logs like we do for configuration definitions?
- Do all these novelties and changes require a new Groovy module major version, i.e.
2.5
?- Probably they do.
/modules/groovy/apps/groovy/subApps