Adding Groovy support

A place to discus the development of leJOS for the EV3. Please do not use this forum to post questions about how to use leJOS or to report problems etc.

Adding Groovy support

Postby rvanderwerf » Thu Mar 13, 2014 5:05 am

I'm looking to add Groovy language support and want to add the jar libraries onto the SD card so my .jar files can use the supporting libraries. Where is the best place to put these, and is this something if I sent a pull request and added sample apps you guys would be interested in adding in?


Cheers

Ryan
rvanderwerf
New User
 
Posts: 19
Joined: Thu Mar 13, 2014 5:00 am

Re: Adding Groovy support

Postby lawrie » Thu Mar 13, 2014 9:12 am

Perhaps /home/root/lejos/libgroovy.

Yes, I think adding groovy support to lejos would be good. I am not sure how pull requests are dealt with on sourceforge, but I am sure we will find out.
lawrie
leJOS Team Member
 
Posts: 909
Joined: Mon Feb 05, 2007 1:27 pm

Re: Adding Groovy support

Postby gloomyandy » Thu Mar 13, 2014 11:32 am

I'm not sure we want to get into adding lots of different .jar files into the standard leJOS distribution, this would mean we have to look after those files and test them and update them for each release. I think it would be better to create a project that can use something like the ssl copy mechanisms to add the files to an existing install. Or perhaps modify the standard install to provide an easy way to allow additional .jars to be added by the user.
User avatar
gloomyandy
leJOS Team Member
 
Posts: 3881
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: Adding Groovy support

Postby rvanderwerf » Thu Mar 13, 2014 4:15 pm

So one idea I was going to take a crack at was porting all of the Ant build stuff into Gradle. Instead of packaging all of these jars or users having to go fetch them (like jsh type stuff) gradle wrapper can auto-download and install gradle, grab remote dependencies, and run the tasks to build (and make the sd card directory layout, like dropping the Groovy + other jars there).

I'm working on a Gradle tutorial series for Packt right now and it seems like a good fit, and may lower developer frustration who want to start writing stuff and just 'make it go' while also digging a little deeper. I think it might also eventually eliminate need for a patchwork of shell scripts + ant build.xml files. I.e. building code and samples could be a hierarchy of linked gradle modules that wouldn't depend so much on eclipse to build.

I'll take a crack and this and report back how well if works. Not sure on pull requests on SF as most people have moved to github, but at least they support git now! Is that something you guys have looked into (moving to github)? It's great for community code collaboration and management of pull requests saves so much time.
rvanderwerf
New User
 
Posts: 19
Joined: Thu Mar 13, 2014 5:00 am

Re: Adding Groovy support

Postby fuzzycow » Thu Mar 13, 2014 5:10 pm

I tried using groovy on Ev3 (for the sake of fast prototyping and gpars framework), but script "startup" times where prohibitive :(

Did you manage to get Groovy scripts to start in a reasonable time?

Perhaps running a persistent interpreter and script loading via GroovyScriptEngine could be considered.
fuzzycow
Novice
 
Posts: 26
Joined: Sun Sep 08, 2013 4:33 pm

Re: Adding Groovy support

Postby rvanderwerf » Thu Mar 13, 2014 6:15 pm

Indeed I think some kind of daemon that stays loaded would be key to make it fast enough. It's slow enough already to boot up just lejos just my itself. Gradle actually does that same trick to make builds so fast. However memory isn't unlimited in the ev3 (I wish it was an arm6 or 7 with hard float jvm) so I'll see what I can whip up. Thanks for the tips, I'm just getting started on this for my work on a workshop this summer, and experiences you all have faced or issues I would love to hear.


Ryan
rvanderwerf
New User
 
Posts: 19
Joined: Thu Mar 13, 2014 5:00 am

Re: Adding Groovy support

Postby hugheaves » Tue Mar 18, 2014 8:20 am

I'm not a Groovy developer, but I believe you can use Maven with Groovy. The reason that might be useful is that it's fairly easy to configure Maven to automatically install any dependency jars of a program when the program itself is installed. With the right settings, Maven is also smart enough to only copy jars that have changed between builds. On my EV3, that means it only takes 5-6 seconds to install updated programs, even if the program has a lot of large dependencies.

If you want to give it a try, I have a parent POM that "automagically" does all this for you. If you use this parent pom, and do a "mvn install", it will build the program, and install it to the EV3 along with any other jars that are needed.

Here's an example pom.xml, that uses the parent pom:

Code: Select all
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
   <modelVersion>4.0.0</modelVersion>
   <artifactId>elevator</artifactId>
   <packaging>jar</packaging>

    <repositories>
        <repository>
            <id>robotjava-repo</id>
            <url>http://www.robotjava.org/maven2</url>
        </repository>
    </repositories>
   
   <parent>
      <groupId>org.robotjava.ev3</groupId>
      <artifactId>ev3-program-parent</artifactId>
      <version>0.0.1-SNAPSHOT</version>
   </parent>

   <properties>
      <lejos.home>/home/lejos/programs</lejos.home>
      <!-- <ev3.host>ev3</ev3.host> Defaults to "ev3", override if needed -->
      <main-class>com.hugheaves.lego.elevator.Elevator</main-class>
   </properties>
</project>
hugheaves
New User
 
Posts: 16
Joined: Sun Dec 29, 2013 5:35 pm

Re: Adding Groovy support

Postby rvanderwerf » Thu Mar 20, 2014 4:56 am

Thanks for the response.. I'm not sure how maven would help, I can also use the gradle wrapper which will do the same...

I've been going down the path of groovyserv, it's a daemon to accelerate Groovy code execution. You call it with a native client and it pipes the code into an already running jvm with groovy, so it doesn't have to start/stop the jvm and groovy each time. Using the codesourcery arm cross compiler building groovyclient native. I got that built for arm v5, and running on the ev3. I've got the client compiled, however the daemon wrapper is in bash which isn't available on the ev3 so I'm converting that to work with the sh shell that's already installed.

I've hit a few roadblocks though running the server component: a big one is there is no actual JDK(javac) for arm v5, just the JRE, and it wants to look for javac (well groovy does really). I grabbed jdk8 for armv5, but it also lacks javac as well. I'm kind of stuck there. There are a couple of other small issues on the way it tries to shell and call ps (ps on ev3 doesn't seem to support the normal parameters), as well as some socket devices it looks for. I may go with sometime much simpler like springloaded and require the user to just pre-compile the groovy scripts on their x86 machine with the regular groovy compiler. Groovyserv just may be way overkill here :) The spirit of what I'd like is to build a groovy DSL for programming the robot with syntactic sugar on top of java and use the MOP while doing so. Running a straight Groovy file is sugar on top, but without javac that may not be possible.

I've heard some chatter of the folks that make icedtea making a arm javac, but I think it's for armv6 and not v5. Maybe ev4 will have a arm7 or better :)
rvanderwerf
New User
 
Posts: 19
Joined: Thu Mar 13, 2014 5:00 am

Re: Adding Groovy support

Postby hugheaves » Thu Mar 20, 2014 6:54 pm

rvanderwerf wrote:I'm looking to add Groovy language support and want to add the jar libraries onto the SD card so my .jar files can use the supporting libraries.


rvanderwerf wrote:Thanks for the response.. I'm not sure how maven would help, I can also use the gradle wrapper which will do the same...


Ah, I may have misunderstood. I thought you were looking for an easy way to deploy any "jar dependencies" of your app to the EV3. I didn't realize you could use gradle wrapper to actually copy the jars to the EV3...
hugheaves
New User
 
Posts: 16
Joined: Sun Dec 29, 2013 5:35 pm

Re: Adding Groovy support

Postby epascual » Fri Apr 04, 2014 11:36 pm

Hi everybody,

Maybe I've overlooked or misunderstood something, but I'm quite a bit surprised to see big guns such as Maven and Gradle mentioned for doing EV3 programming.

I've used Maven a lot for several years, and if it's ok for big projects having a lot of external dependencies to manage, it can also turns into big headaches. I'm presently not sure that the EV3 project size would real justify the price to pay for Mavenify it. My experience tends to demonstrate that writing and maintaining POMs is not really a task for faint of the heart and that it can very quickly make you loose big amount of life expectancy too a soon as it goes out of control :) To tell you the whole story, we just stopped using it in our project (composed of multiple inter-related module which tend to mess up Maven's mechanisms) and revert to a basic Makefile based approach.

In addition, even the slightest Maven build tends to take ages to go. Our new option just cut these times by 10 at least ;)

But once again, maybe I've understood something the wrong way.

Cheers.
Eric PASCUAL - POBOT association VP & co-founder - http://www.pobot.org
epascual
Active User
 
Posts: 123
Joined: Sun Jan 17, 2010 12:15 am
Location: Sophia-Antipolis (France)

Re: Adding Groovy support

Postby rvanderwerf » Sun Apr 06, 2014 3:24 am

epascual wrote:Hi everybody,

Maybe I've overlooked or misunderstood something, but I'm quite a bit surprised to see big guns such as Maven and Gradle mentioned for doing EV3 programming.

I've used Maven a lot for several years, and if it's ok for big projects having a lot of external dependencies to manage, it can also turns into big headaches. I'm presently not sure that the EV3 project size would real justify the price to pay for Mavenify it. My experience tends to demonstrate that writing and maintaining POMs is not really a task for faint of the heart and that it can very quickly make you loose big amount of life expectancy too a soon as it goes out of control :) To tell you the whole story, we just stopped using it in our project (composed of multiple inter-related module which tend to mess up Maven's mechanisms) and revert to a basic Makefile based approach.

In addition, even the slightest Maven build tends to take ages to go. Our new option just cut these times by 10 at least ;)

But once again, maybe I've understood something the wrong way.

Cheers.


That's why Gradle has gotten so popular. It makes the rigor of Maven more flexible, but the mess of Ant more organized. Where I disagree Make is just pure evil, there is no purpose for such madness other than fear of change for a Java system(It even supports native now). It runs a daemon in the background so it's faster than ant and maven by themselves by a wide margin. I don't think anyways means running gradle in EV3 directly, just for packaging and deploying lejos stuff to it :)

I see you already have build.xml's defined, so we can create a multi-module java project in gradle and in each one of those directly import the build.xml so you don't have to rewrite it all. At that point Gradle tasks can extend a ant build.xml task, and vise-versa. Having the gradle wrapper checked in means you just run the build executable (.bat on windows or shells script) and it auto-installs gradle so you don't need to do anything as long as java is installed (Don't even need ant or maven!)

I'll try to make a since sample project wrapper soon so you see a working example for the lejos project :)


On another note I got .13 of Groovyserv more or less working (I had to strip out the security) however v.14 doesn't work so well as it has all kinds of native library dependencies that are hard to track down for armv5. Memory is very tight though, with the main lejos menu running there is only 24mb or so free. I see there is jsch used for lejos, what is it using that for? I saw a trick someone did a few years ago using that to keep the JVM running, and inject groovy runtime code via SSH into the jvm to help with startup times.

Cheers

Ryan
rvanderwerf
New User
 
Posts: 19
Joined: Thu Mar 13, 2014 5:00 am

Re: Adding Groovy support

Postby epascual » Sun Apr 06, 2014 9:56 am

Thanks Ryan for the enlightenments on the topic.

So life seems to be happier in Gradle's camp, and I trust your experience. I confess knowing almost nothing about it, apart the name and a couple of Web pages I could read about. But I never tried it... yet ;)

Just a question more. From what I can see, the EV3 ecosystem is mainly composed of a core library (ev3classes), a couple of utilities meant to run on the developper's workstation and a collection of examples. Apart their dependence on ev3classes, all other applications seems to be independent from each others (at least the ones I have studied).

So where is the real need for a build tool better than Ant ? After all, once you have a build.xml template which you can parametrize for your own application, it does its job pretty well and without any special worry. I've used this approach for my private projects, and have also applied it to projects of college students I'm coaching (and who are just here for learning Java, and don't know anything about Ant of course ;)), and it works fine.

I'm not trying to say that Ant is the ultimate solution and that we don't have to move from it. Just trying to have a better understanding of the rationale behind the proposal.

Best regards

Eric

PS: as you may have understood, the Maven based project I've mentioned is a professional one without any connection to LeJOS. It is a quite complex embedded modular environment based on OSGi used for research projects in the domain of smart buildings and alike. We needed a build tool smarter than Ant since the dependency graph (both for external dependencies and intra-environment ones) is a bit complex, and involves components which are themselves under development.
Eric PASCUAL - POBOT association VP & co-founder - http://www.pobot.org
epascual
Active User
 
Posts: 123
Joined: Sun Jan 17, 2010 12:15 am
Location: Sophia-Antipolis (France)

Re: Adding Groovy support

Postby gloomyandy » Sun Apr 06, 2014 10:32 am

There is a little more to leJOS for the EV3 than just the class libraries. There is the SD card. Which is rather complex to create...
User avatar
gloomyandy
leJOS Team Member
 
Posts: 3881
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: Adding Groovy support

Postby epascual » Sun Apr 06, 2014 11:02 am

Oh yes, I see.

Thx Andy for the reminder ;)
Eric PASCUAL - POBOT association VP & co-founder - http://www.pobot.org
epascual
Active User
 
Posts: 123
Joined: Sun Jan 17, 2010 12:15 am
Location: Sophia-Antipolis (France)

Re: Adding Groovy support

Postby rvanderwerf » Mon Apr 07, 2014 4:45 am

Well certainly there is a big win for newcomers, who can simply checkout the project, and run the build, components and dependencies are automatically downloaded (included external jars, gradle itself, ant functions). The user then has a lower frustration level because the only need java installed to get going, and there are no ANT_HOME things to download separately, (or maven) etc. I'd think getting up and running quickly might get more users on the system in the long run. Android is being built with it as well, which is quite more complex example.

It's pretty simple to start, but you can get up and running with lejos faster :) There is one gotcha, for each subprojects, if we import the build.xml directly, you can't use the java plugin in the build.gradle, because the task names conflict (gradle java plugin adds tasks like 'clean,jar,compile,etc'. If an entire subproject is ported over to gradle one a a time it would make the transition smoother or we can use different names in the build.xml files so they don't conflict.

Right now I have a root project in the root 'lejos-ev3' directory with a build.gradle file, and a settings.gradle that includes the other projects below it. Each project dir has a build.gradle file inside of it that imports the existing build.xml. I have it running without installing ant at all, and I can this far run all of the ant tasks. Just run 'gradle <ant task name> under any project dir and it just works. :) In some cases I found a few dirs with no build.xml, it only took a little bit to make those gradle builds compile the source that was in there. The only project I had any issues with was the 'EV3AndroidMenu' - I think it was because my SDK was for Android 19.0.1 and it was made for Android 16.0. Since the gradle dsl uses Groovy, you can do lots of neat things with the projects like doFirst, doLast, subprojects, etc off the root build.gradle. Also if you load the build.gradle in the root dir on IntelliJ Idea, it will see all of the subprojects and everything will work.

I have created a pull request at https://sourceforge.net/p/lejos/ev3/merge-requests/1/
It won't break any existing functionality

Cheers

Ryan

-----------------

So life seems to be happier in Gradle's camp, and I trust your experience. I confess knowing almost nothing about it, apart the name and a couple of Web pages I could read about. But I never tried it... yet ;)

Just a question more. From what I can see, the EV3 ecosystem is mainly composed of a core library (ev3classes), a couple of utilities meant to run on the developper's workstation and a collection of examples. Apart their dependence on ev3classes, all other applications seems to be independent from each others (at least the ones I have studied).

So where is the real need for a build tool better than Ant ? After all, once you have a build.xml template which you can parametrize for your own application, it does its job pretty well and without any special worry. I've used this approach for my private projects, and have also applied it to projects of college students I'm coaching (and who are just here for learning Java, and don't know anything about Ant of course ;)), and it works fine.

I'm not trying to say that Ant is the ultimate solution and that we don't have to move from it. Just trying to have a better understanding of the rationale behind the proposal.

Best regards

Eric

PS: as you may have understood, the Maven based project I've mentioned is a professional one without any connection to LeJOS. It is a quite complex embedded modular environment based on OSGi used for research projects in the domain of smart buildings and alike. We needed a build tool smarter than Ant since the dependency graph (both for external dependencies and intra-environment ones) is a bit complex, and involves components which are themselves under development.[/quote]
rvanderwerf
New User
 
Posts: 19
Joined: Thu Mar 13, 2014 5:00 am

Next

Return to leJOS EV3 Development

Who is online

Users browsing this forum: No registered users and 0 guests

more stuff