<@U0CHHN4F4> I am trying to leverage new scripting...
# scripting
s
@ilya.chernikov I am trying to leverage new scripting support in Spring Fu, but I can't make it work like I need. At some point you said that
*.kts
files will be compiled automatically. I have a
src/main/resources/application.kts
file that is defining
val foo = ...
and I would like to access
foo
from my
src/main/kotlin
source code. Is that use case supported? Does it require specific configuration?
i
Hi @sdeleuze First you probably need to put script into source roots, they are not compiled automatically from resources. And then to be able to access script properties and functions statically from other sources, you’ll need changes that will come with 1.2.60 (the planned EAP next week will most likely contain everything needed). With the 1.2.50 the only way is to use reflection, like:
Copy code
val scriptClass = Class.forName("Application")
val ctor = scriptClass.getConstructor() // the params depend on your definition
...
s
Ok I will wait for
1.2.60
EAP next week then
Any chance you could provide an easy way to configure
*.kts
compilation from resources? The point of app configuration is to be separated from source code and I would like it to be optionaly externaliable.
So putting it in resources like we do for
application.properties
would be really nice
My goal is to get it compiled by default with the huge compiler dep
And optionnaly support dynalic evauationb at startup if te compiler dep is here
In such case the kts file will be outside of the JAR
i
This to my mind contradicts to the goal of having scripts to be statically resolvable on the compilation time. So, to my mind, either you want it to be part of the compilation - in this case you should put it to the place where it could be picked up by the compiler that compiles your other sources, or you want it dynamically compiled on the runtime and then you add the compiler to your dependencies and using provided infrastructure write a host the does what you want. Which case are you aiming at?
So, you can compile it from resources on runtime, we do not have ready-made helpers that will do it automatically, but it should be quite easy to write. If this is your case, I can try to bring some sample code, if you like.
s
Ok make sense. Yes I would like to update my dynamic configuratin module (currently based on the JSR API) to the new scripting support. See https://github.com/spring-projects/spring-fu/blob/master/modules/dynamic-configuration/. Any example of the new API would help.
Also any tips that could allow to limit the size of the dependencies and the startup time (like bytecode caching for n+1 runs) would help.
i
Ok, I’ll try to come up with some sample in the next few days. (I need to finish the changes to the 1.2.60 first though.)
s
Thanks
i
Hi @sdeleuze I tried to make a good example for the case of your configuration module, but unfortunately there is at least one limitation that make it impossible now - the regular scripts don’t have automatically calculated results. Only for REPL the last expression is returned from the evaluation as a result, and JSR223 API is based on the REPL. For the regular scripts the result of the
eval
call is the script class instance. Since you’re using the result returned from the script engine, I think it would be easier if you’ll continue to use JSR223 for now.
The problem itself is quite likely will be addressed in one of the following releases, and then you’ll be able to switch, if needed.
s
Ok thanks, please let me know when this will be fixed.
@ilya.chernikov Hey, any update on that topic? Should I keep using JSR 223 or is there anything new I should use?
i
Hi @sdeleuze, Unfortunately the issue with the return value is still unresolved. I plan to come back to it soon after release of 1.3. And about the same time I plan to assemble some compilation cache example. Then I’ll be hopefully ready to make an example for your case.
s
Ok
Thanks for the feedback