Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 3
    • Fix Version/s: None
    • Component/s: Scripting
    • Labels:
      None
    • Environment:
      all

      Description

      Implement Groovy as an option for scripting language support. A patch with a possible implementation will be attached

      1. pom.xml
        4 kB
        Felix Meschberger
      2. groovy.tar.gz
        14 kB
        Christian Sprecher
      3. groovy-engine-1.0.jar
        11 kB
        Christian Sprecher
      4. diff.txt
        18 kB
        Christian Sprecher

        Activity

        Hide
        Christian Sprecher added a comment -

        Patch containing a project in sling/scripting/groovy which enables groovy support. No additional source code is needed

        Show
        Christian Sprecher added a comment - Patch containing a project in sling/scripting/groovy which enables groovy support. No additional source code is needed
        Hide
        Christian Sprecher added a comment -

        Groovy ScriptEngine implementation, originally from https://scripting.dev.java.net/files/documents/4957/37593/jsr223-engines.zip.

        Show
        Christian Sprecher added a comment - Groovy ScriptEngine implementation, originally from https://scripting.dev.java.net/files/documents/4957/37593/jsr223-engines.zip .
        Hide
        Christian Sprecher added a comment -

        from the sling/scripting/groovy/src/main/resources/META-INF/NOTICE file

        ============================================

        Apache Sling Groovy Scripting Support
        Copyright 2007 The Apache Software Foundation

        This product includes software developed at
        The Apache Software Foundation (http://www.apache.org/).

        This product includes software developed at
        Groovy project in The Codehaus (http://groovy.codehaus.org/).

        =============
        Current state
        =============

        ======================
        How to use/How to test
        ======================

        ============
        Is that all?
        ============
        Yeah, at the moment. Please note that not one line of code had to be written to enable groovy support. This is nice.

        ===========
        Whats next?
        ===========

        • please someone check the pom.xml. There are many explicit excludes in the bundle plugin, this smells
        • Groovy Servlet Pages (gsp) support
        • do not use groovy-all.jar (dependency clean-up)
        • some kickass sample to have the crowd go "wow" (some gpath magic might well do it)
        Show
        Christian Sprecher added a comment - from the sling/scripting/groovy/src/main/resources/META-INF/NOTICE file ============================================ Apache Sling Groovy Scripting Support Copyright 2007 The Apache Software Foundation This product includes software developed at The Apache Software Foundation ( http://www.apache.org/ ). This product includes software developed at Groovy project in The Codehaus ( http://groovy.codehaus.org/ ). ============= Current state ============= pure groovy JSR 223-support, i.e. no special html markup handled makes use of groovy-engine.jar file found at https://scripting.dev.java.net/files/documents/4957/37593/jsr223-engines.zip (unfortunately not found in any maven repository) ====================== How to use/How to test ====================== first have the sling/scripting/groovy project created and deployed (mvn clean install) first time you have to add groovy-engine to your local repository change sling/launchpad/launchpad-webapp/pom.xml to use the groovy scripting engine: <dependency> <groupId>groovy</groupId> <artifactId>groovy-all</artifactId> <version>1.0</version> </dependency> startup jetty (mvn jetty:run) and check, if the groovy support is activated: check under http://localhost:8888/sling/list wether "Sling - Scripting - Groovy Support" is set then follow the steps under http://incubator.apache.org/sling/site/discover-sling-in-15-minutes.html but instead of building a html.esp, create a html.groovy containing one line println resource.node.getProperty("title").string therefore the last step reads as curl -X PUT -d @html.groovy http://admin:admin@localhost:8888/dav/default/apps/foo/bar/html.groovy navigating to http://localhost:8888/content/mynode.html shows groovy in action ... ============ Is that all? ============ Yeah, at the moment. Please note that not one line of code had to be written to enable groovy support. This is nice. =========== Whats next? =========== please someone check the pom.xml. There are many explicit excludes in the bundle plugin, this smells Groovy Servlet Pages (gsp) support do not use groovy-all.jar (dependency clean-up) some kickass sample to have the crowd go "wow" (some gpath magic might well do it)
        Hide
        Christian Sprecher added a comment -

        the whole sling/scripting/groovy project

        Show
        Christian Sprecher added a comment - the whole sling/scripting/groovy project
        Hide
        Felix Meschberger added a comment - - edited

        Thanks for this submission. We certainly add this, but ...

        -> You propose to add Version 1.0. I would rather suggest to go with 1.5.4. WDYT ?

        -> The Groovy ScriptEngine is not available from a public Maven repository. This is IMHO a bigger problem, as I do not want to put binary artifacts into the SVN if not really required - and I am not even talking about licensing issues yet...

        So I posted on the dev(at)scripting.dev.java.net mailing list about the possibilities to add maven artifacts of the ScriptEngines to some public maven repository. Until this issue has been resolved, I would like to put this issue on hold.

        Disucssions are of course open

        Show
        Felix Meschberger added a comment - - edited Thanks for this submission. We certainly add this, but ... -> You propose to add Version 1.0. I would rather suggest to go with 1.5.4. WDYT ? -> The Groovy ScriptEngine is not available from a public Maven repository. This is IMHO a bigger problem, as I do not want to put binary artifacts into the SVN if not really required - and I am not even talking about licensing issues yet... So I posted on the dev(at)scripting.dev.java.net mailing list about the possibilities to add maven artifacts of the ScriptEngines to some public maven repository. Until this issue has been resolved, I would like to put this issue on hold. Disucssions are of course open
        Hide
        Bertrand Delacretaz added a comment - - edited

        Felix, do you have an URL for the thread on dev (at) scripting.dev.java.net, so that people can follow the discussion?

        We could also ask the Groovy people directly, about releasing the ScriptEngine in a Maven repository, or do you think that's out of their scope?

        The Groovy license if not a problem, I downloaded Groovy 1.5.4 to check and it's Apache-licensed, and uses http://asm.objectweb.org/ which also uses an Apache-like license.

        Show
        Bertrand Delacretaz added a comment - - edited Felix, do you have an URL for the thread on dev (at) scripting.dev.java.net, so that people can follow the discussion? We could also ask the Groovy people directly, about releasing the ScriptEngine in a Maven repository, or do you think that's out of their scope? The Groovy license if not a problem, I downloaded Groovy 1.5.4 to check and it's Apache-licensed, and uses http://asm.objectweb.org/ which also uses an Apache-like license.
        Hide
        Felix Meschberger added a comment - - edited

        > URL

        Yes, I now have it (was not available yet in the archives upon my post):

        https://scripting.dev.java.net/servlets/ReadMsg?list=dev&msgNo=55

        > Groovy people for ScriptEngine

        The ScriptEngine does not come from the Groovy people but from scripting.dev.java.net. Therefore I posted my question there. In fact, they provide a whole range of ScriptEngine implementations. So, if they would deploy to a public maven repository, we could almost immediately make use of these.

        > Licensing

        I agree, that licenses for use are not an issue, neither for Groovy itself nor for the ScriptEngine implementation from dev.java.net which seems BSD-like. The problem regarding licensing I have is putting a binary from dev.java.net into the Apache SVN.

        Show
        Felix Meschberger added a comment - - edited > URL Yes, I now have it (was not available yet in the archives upon my post): https://scripting.dev.java.net/servlets/ReadMsg?list=dev&msgNo=55 > Groovy people for ScriptEngine The ScriptEngine does not come from the Groovy people but from scripting.dev.java.net. Therefore I posted my question there. In fact, they provide a whole range of ScriptEngine implementations. So, if they would deploy to a public maven repository, we could almost immediately make use of these. > Licensing I agree, that licenses for use are not an issue, neither for Groovy itself nor for the ScriptEngine implementation from dev.java.net which seems BSD-like. The problem regarding licensing I have is putting a binary from dev.java.net into the Apache SVN.
        Hide
        Jukka Zitting added a comment -

        > The problem regarding licensing I have is putting a binary from dev.java.net into the Apache SVN.

        It's fine as long as the license is acceptable and our LICENSE and NOTICE files are updated accordingly. The same rules apply also for releases that include such externally developed components.

        Show
        Jukka Zitting added a comment - > The problem regarding licensing I have is putting a binary from dev.java.net into the Apache SVN. It's fine as long as the license is acceptable and our LICENSE and NOTICE files are updated accordingly. The same rules apply also for releases that include such externally developed components.
        Hide
        Paul King added a comment -

        The groovy all jar should now incorporate this functionality. It should be in the main maven repo in a couple of weeks time when groovy-1.6-rc-1 is released. In the meantime, if you are keen, you can point to the codehaus maven snapshot repo:

        http://snapshots.repository.codehaus.org

        with this pom info:

        <groupId>org.codehaus.groovy</groupId>
        <artifactId>groovy-all</artifactId>
        <version>1.7-beta-1-SNAPSHOT</version>
        

        Just to summarise: you don't need groovy-engine.jar anymore. The groovy jar should contain the equivalent functionality and META-INF/services entry. It should run fine on Java 1.6 or on 1.5 if you supply a backported jsr-223 implementation, e.g. livetribe-jsr223.

        Cheers, Paul.

        Show
        Paul King added a comment - The groovy all jar should now incorporate this functionality. It should be in the main maven repo in a couple of weeks time when groovy-1.6-rc-1 is released. In the meantime, if you are keen, you can point to the codehaus maven snapshot repo: http://snapshots.repository.codehaus.org with this pom info: <groupId> org.codehaus.groovy </groupId> <artifactId> groovy-all </artifactId> <version> 1.7-beta-1-SNAPSHOT </version> Just to summarise: you don't need groovy-engine.jar anymore. The groovy jar should contain the equivalent functionality and META-INF/services entry. It should run fine on Java 1.6 or on 1.5 if you supply a backported jsr-223 implementation, e.g. livetribe-jsr223. Cheers, Paul.
        Hide
        Felix Meschberger added a comment -

        Paul, Thanks for the heads up. I tested it and it seems to work.

        Show
        Felix Meschberger added a comment - Paul, Thanks for the heads up. I tested it and it seems to work.
        Hide
        Felix Meschberger added a comment -

        Proposed POM for integrating Groovy support.

        Looking at this, I wonder, whether it would make more sense for groovy-all.jar to be a bundle in itself and thus be able to simply drop it into Sling.

        Show
        Felix Meschberger added a comment - Proposed POM for integrating Groovy support. Looking at this, I wonder, whether it would make more sense for groovy-all.jar to be a bundle in itself and thus be able to simply drop it into Sling.
        Hide
        Paul King added a comment -

        The groovy-all and groovy jars should both already be OSGi bundles. We have more inclusive header settings than what I believe you are trying to create in the proposed pom though I am unsure whether that will be a problem.

        Show
        Paul King added a comment - The groovy-all and groovy jars should both already be OSGi bundles. We have more inclusive header settings than what I believe you are trying to create in the proposed pom though I am unsure whether that will be a problem.
        Hide
        Felix Meschberger added a comment -

        Update for our dear Sling community:

        The Groovy 1.6 branch already contains both the JSR-223 ScriptEngine[Factory] implementations and OSGi headers and can be deployed into Sling as built by ant. See [1].

        So rather than doing our own integration, I would suggest we just create a link to Groovy to grab the binary from there.

        [1] http://markmail.org/message/7sqscr5y2mbk6jko

        Show
        Felix Meschberger added a comment - Update for our dear Sling community: The Groovy 1.6 branch already contains both the JSR-223 ScriptEngine [Factory] implementations and OSGi headers and can be deployed into Sling as built by ant. See [1] . So rather than doing our own integration, I would suggest we just create a link to Groovy to grab the binary from there. [1] http://markmail.org/message/7sqscr5y2mbk6jko
        Hide
        Christian Sprecher added a comment -

        Hey guys

        I am unsure on how to use the plain 1.6 jar within Sling: while the bundle installs without any problems, I am not able to create a .groovy script and to use it. I tried it with installing the 1.6-beta-2 groovy-all.jar (didnt work) and again with my proposed pom.xml (with the downloaded scripting engine).

        Did anyone succeed in using *.groovy scripts with "only" the groovy-all.jar?

        Show
        Christian Sprecher added a comment - Hey guys I am unsure on how to use the plain 1.6 jar within Sling: while the bundle installs without any problems, I am not able to create a .groovy script and to use it. I tried it with installing the 1.6-beta-2 groovy-all.jar (didnt work) and again with my proposed pom.xml (with the downloaded scripting engine). Did anyone succeed in using *.groovy scripts with "only" the groovy-all.jar?
        Hide
        Felix Meschberger added a comment -

        What I did is checkout the 1.6 branch, build it (myself) and this seemed to work.

        I created the groovy scripts using web dav access.

        Unfortunately you have to build the Groovy library on your own for now, since the published binaries are not complete yet. See the new page on the Sling site [1] explaining what to do (this page is fresh it may only be available some time after this writing)

        [1] http://incubator.apache.org/sling/site/groovy-support.html

        Show
        Felix Meschberger added a comment - What I did is checkout the 1.6 branch, build it (myself) and this seemed to work. I created the groovy scripts using web dav access. Unfortunately you have to build the Groovy library on your own for now, since the published binaries are not complete yet. See the new page on the Sling site [1] explaining what to do (this page is fresh it may only be available some time after this writing) [1] http://incubator.apache.org/sling/site/groovy-support.html
        Hide
        Paul King added a comment -

        You can get a built version of Groovy (1.7 snapshot) from the Cruise CI server. Go to:
        http://build.canoo.com/groovy/
        then 'Build Artifacts' then 'Deliverables'.

        There are also TeamCity, Hudson (I think) and Bamboo CI servers. Some of those might also keep build jars.

        Alternatively, point to the one from the maven snapshots repo mentioned in an earlier comment.
        If you need I can push a 1.6 snapshot into the maven snapshot repo but 1.7 isn't much different to 1.6 at the moment.

        Show
        Paul King added a comment - You can get a built version of Groovy (1.7 snapshot) from the Cruise CI server. Go to: http://build.canoo.com/groovy/ then 'Build Artifacts' then 'Deliverables'. There are also TeamCity, Hudson (I think) and Bamboo CI servers. Some of those might also keep build jars. Alternatively, point to the one from the maven snapshots repo mentioned in an earlier comment. If you need I can push a 1.6 snapshot into the maven snapshot repo but 1.7 isn't much different to 1.6 at the moment.
        Hide
        Felix Meschberger added a comment -

        Thanks Paul for the update on this. I have updated the groovy-suporpt.html page with your comments. Should be available soon.

        Show
        Felix Meschberger added a comment - Thanks Paul for the update on this. I have updated the groovy-suporpt.html page with your comments. Should be available soon.
        Hide
        Paul King added a comment -

        The RC-1 build of 1.6 is not far away now, so once that is out I will send another update which should simplify instructions a little further.

        Show
        Paul King added a comment - The RC-1 build of 1.6 is not far away now, so once that is out I will send another update which should simplify instructions a little further.
        Hide
        Felix Meschberger added a comment -

        Cool. Looking forward to it.

        Show
        Felix Meschberger added a comment - Cool. Looking forward to it.
        Hide
        Christian Sprecher added a comment -

        Ah, my bad, I didn't read the whole explanations, and tried it with Groovy 1.6-beta-2, sorry for the confusion.

        Definitely looking forward to try this at home .

        Show
        Christian Sprecher added a comment - Ah, my bad, I didn't read the whole explanations, and tried it with Groovy 1.6-beta-2, sorry for the confusion. Definitely looking forward to try this at home .
        Hide
        Christian Sprecher added a comment -

        Ok, I have tested it. It works.

        Now, what is the best strategy when you try to access JCR classes like QueryManager from within a Groovy script?
        I.e. I have a fully functional groovy plugin, which I don't want to change. But still I want to access additional classes. What is OSGI best practise in such cases?

        Show
        Christian Sprecher added a comment - Ok, I have tested it. It works. Now, what is the best strategy when you try to access JCR classes like QueryManager from within a Groovy script? I.e. I have a fully functional groovy plugin, which I don't want to change. But still I want to access additional classes. What is OSGI best practise in such cases?
        Hide
        Felix Meschberger added a comment -

        Agreed. I have also tested such a use case and it looks like the Groovy bundle cannot see the required classes.

        The only viable solution, I know of, and which we also use in our own ScriptEngine implementation bundles, is to set the DynamicImport-Package header to "*" meaning to try to resolve all unknown classes in the framework on-demand and only failing if the classes are not available from any exports in the framework.

        I have posted a potential extension to the Groovy build in [1].

        In short, it only requires a very small patch to the Groovy build.xml file (against the Groovy 1.6 branch):

        Index: build.xml
        ===================================================================
        — build.xml (Revision 14334)
        +++ build.xml (Arbeitskopie)
        @@ -496,6 +496,7 @@
        <attribute name="Bundle-RequiredExecutionEnvironment" value="@

        {bundleEnvironment}

        " />
        <attribute name="Eclipse-BuddyPolicy" value="dependent"/>
        <attribute name="Eclipse-LazyStart" value="true"/>
        + <attribute name="DynamicImport-Package" value="*"/>
        </manifest>
        </sequential>
        </macrodef>

        [1] http://markmail.org/message/47n2ow2jlo553jvk

        Show
        Felix Meschberger added a comment - Agreed. I have also tested such a use case and it looks like the Groovy bundle cannot see the required classes. The only viable solution, I know of, and which we also use in our own ScriptEngine implementation bundles, is to set the DynamicImport-Package header to "*" meaning to try to resolve all unknown classes in the framework on-demand and only failing if the classes are not available from any exports in the framework. I have posted a potential extension to the Groovy build in [1] . In short, it only requires a very small patch to the Groovy build.xml file (against the Groovy 1.6 branch): Index: build.xml =================================================================== — build.xml (Revision 14334) +++ build.xml (Arbeitskopie) @@ -496,6 +496,7 @@ <attribute name="Bundle-RequiredExecutionEnvironment" value="@ {bundleEnvironment} " /> <attribute name="Eclipse-BuddyPolicy" value="dependent"/> <attribute name="Eclipse-LazyStart" value="true"/> + <attribute name="DynamicImport-Package" value="*"/> </manifest> </sequential> </macrodef> [1] http://markmail.org/message/47n2ow2jlo553jvk
        Hide
        Paul King added a comment -

        There is a 1.7 snapshot with the 'DynamicImport-Package' amendment available at the aforementioned snapshot repo, i.e. here:

        http://snapshots.repository.codehaus.org/org/codehaus/groovy/groovy-all/1.7-beta-1-SNAPSHOT/

        Merging on to the 1.6 branch shortly.

        Show
        Paul King added a comment - There is a 1.7 snapshot with the 'DynamicImport-Package' amendment available at the aforementioned snapshot repo, i.e. here: http://snapshots.repository.codehaus.org/org/codehaus/groovy/groovy-all/1.7-beta-1-SNAPSHOT/ Merging on to the 1.6 branch shortly.
        Hide
        Felix Meschberger added a comment -

        That was fast !

        Thanks alot Paul. Going to update the groovy-support.html page right away.

        Show
        Felix Meschberger added a comment - That was fast ! Thanks alot Paul. Going to update the groovy-support.html page right away.
        Hide
        Felix Meschberger added a comment -

        Now that Paul King (thanks again) has deployed a Groovy 1.6 RC 1 SNAPSHOT yesterday, which also includes required DynamicImport-Package I assume we can mark this issue resolved.

        I have updated the web page indicating the current download locations.

        If you are satisified with this outcome, please close this issue. Thanks.

        Show
        Felix Meschberger added a comment - Now that Paul King (thanks again) has deployed a Groovy 1.6 RC 1 SNAPSHOT yesterday, which also includes required DynamicImport-Package I assume we can mark this issue resolved. I have updated the web page indicating the current download locations. If you are satisified with this outcome, please close this issue. Thanks.
        Hide
        Christian Sprecher added a comment -

        superb work, thank you all!

        Show
        Christian Sprecher added a comment - superb work, thank you all!

          People

          • Assignee:
            Felix Meschberger
            Reporter:
            Christian Sprecher
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 48h
              48h
              Remaining:
              Remaining Estimate - 48h
              48h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development