I wrote some util classes that capture common utility functions in a groovy
class at script/com/xxx/util/SomeUtility.groovy. However, while running the
app, groovy runner complains that it is not able to find
com.xxx.utilSomeUtility class. After investigating a bit, I realized that
component/xxxx/script is not automatically added into classpath due to which
independent classes are "not seen" by the groovy runner. I was able to
overcome the issue by adding the component/xxxx/script folder to the jvm
classpath at startup. It would be nice if all script folders of all components
are added to classpath by the startup classloader.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The script directory is intended to be used as a resource through the
ResourceFacade, and not through the classpath. If a .groovy file is a script
it is best to run it this way.
If you have .groovy files that represent classes, it is best to compile those
in advance and put them in a jar file on the actual classpath. This has
various benefits, including performance and allowing other classes to depend
on them, and you may also see some benefits from compile time checks.
One annoying thing right now with Moqui is that in the runtime directory and
the component directories anything going on the classpath must be in a jar
file in the "lib" directory. I've been thinking of adding a "classes"
directory for things to go directly onto the classpath, just like in a war
file (ie WEB-INF/lib and WEB-INF/classes).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In commit bb32905 the classes directory I mentioned is now supported for the
runtime and various component directories, and there is a bug fixed where
classpath:// ResourceFacade locations were not getting these extended
classpath entries (because they're only on the Thread's context ClassLoader).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think "classes" is a good facility for the developer.
Moreover, in my opinion compiling the groovy utilty classes (which are not
expected to be high in number) and packaging them into jar is far more painful
than having them loaded on the fly. The advantage in terms of compile time
check and performance is far more outweighed by the freedom developer gets in
refactoring source code and the continuous development. Just my 2 cents.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I wrote some util classes that capture common utility functions in a groovy
class at script/com/xxx/util/SomeUtility.groovy. However, while running the
app, groovy runner complains that it is not able to find
com.xxx.utilSomeUtility class. After investigating a bit, I realized that
component/xxxx/script is not automatically added into classpath due to which
independent classes are "not seen" by the groovy runner. I was able to
overcome the issue by adding the component/xxxx/script folder to the jvm
classpath at startup. It would be nice if all script folders of all components
are added to classpath by the startup classloader.
The script directory is intended to be used as a resource through the
ResourceFacade, and not through the classpath. If a .groovy file is a script
it is best to run it this way.
If you have .groovy files that represent classes, it is best to compile those
in advance and put them in a jar file on the actual classpath. This has
various benefits, including performance and allowing other classes to depend
on them, and you may also see some benefits from compile time checks.
One annoying thing right now with Moqui is that in the runtime directory and
the component directories anything going on the classpath must be in a jar
file in the "lib" directory. I've been thinking of adding a "classes"
directory for things to go directly onto the classpath, just like in a war
file (ie WEB-INF/lib and WEB-INF/classes).
In commit bb32905 the classes directory I mentioned is now supported for the
runtime and various component directories, and there is a bug fixed where
classpath:// ResourceFacade locations were not getting these extended
classpath entries (because they're only on the Thread's context ClassLoader).
I think "classes" is a good facility for the developer.
Moreover, in my opinion compiling the groovy utilty classes (which are not
expected to be high in number) and packaging them into jar is far more painful
than having them loaded on the fly. The advantage in terms of compile time
check and performance is far more outweighed by the freedom developer gets in
refactoring source code and the continuous development. Just my 2 cents.