Classpath for groovy scripts

2011-12-05
2012-09-09
  • Vasanth Kamatgi

    Vasanth Kamatgi - 2011-12-05

    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.

     
  • David E. Jones

    David E. Jones - 2011-12-05

    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).

     
  • David E. Jones

    David E. Jones - 2011-12-05

    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).

     
  • Vasanth Kamatgi

    Vasanth Kamatgi - 2011-12-06

    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.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks