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.

Re: Adding Groovy support

Postby gloomyandy » Mon Apr 07, 2014 9:03 am

Hi Ryan,
I have just received a merge request for your code. I do not intend to merge this code into the main git tree (at least not now). Please do not submit merge requests unless you have already agreed that we want the code in the main tree. One of the reasons for this section of the forum is to allow people to discus potential new features like this.

To be honest I have no idea if this is a good or bad thing. At the moment I don't have the time to pull this code and evaluate it. I have asked the other leJOS developers to take a look at this thread and comment.

One thing that concerns me is that there seem to be a number of projects (like the snapshot, samples, and various others), that do not seem to have been been touched by your changes, I have no idea if this is correct or not, I'm pretty sure they contain ant scripts, but perhaps they do not require changes.

I think you need to spend some time educating us as to why this is a good thing to have. What advantages does it offer? How is it used? Who will make use of it (leJOS Developers, or leJOS end users). What exactly do the changes you have made do and why have you made them etc.

Andy
User avatar
gloomyandy
leJOS Team Member
 
Posts: 4081
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: Adding Groovy support

Postby lawrie » Mon Apr 07, 2014 5:21 pm

Hi Ryan, I don't think it is a good time to add Gradle support to the project, as there is a lot of restructuring going on. As Andy says, one of the things we need to decide is whether the Gradle support is for leJOS developers or for user projects. Currently there is not much distinction as users have to use Git and build projects like ev3classes, but that won't be true at the next release. The current developers are not particularly keen to use Gradle, so I think you should concentrate on making it work for user projects. For example, we could have an example project with a Gradle build.

We are likely to remove a lot of redundant projects from the repository soon, and restructure the other projects into different jar files, so adding Gradle builds at the moment would just complicate things.

I would also like to understand how the Gradle build interacts with Eclipse and the Gradle Eclipse plugin. You have added a lot of stuff at the root of the repository, which I am not keen on. We currently import individual projects into Eclipse and do all our work in Eclipse. Those files at the level above the current projects would not be visible to Eclipse users.

As Andy says, I think we need more discussion about this, such as what the benefits are, what users it is aimed at, what maintenance the Gradle build code will need, and what the workflow is when using Gradle builds. The leJOS development team are not familiar with Gradle. I have used it very briefly, but do not have a good idea of the benefits of it.

We want to get all the restructuring done, and move to Oracle 8, before considering supporting another build system, but it would be good to understand how it would work and what the benefits are.

Lawrie
lawrie
leJOS Team Member
 
Posts: 922
Joined: Mon Feb 05, 2007 1:27 pm

Re: Adding Groovy support

Postby rvanderwerf » Wed Apr 09, 2014 3:26 am

Sure, I understand the fear of change or unknown without understanding the reasoning - that is quite understandable and a reasonable question to ask before adding it. I did not mean to offend anyone, I'm doing this work anyways on my own fork for the Groovy community to use, I'm just trying to give back to the community to improve the experience of newcomers and bring a wider audience. A pull request is almost no effort at all really (nor is merging one) with git.

What I sent in the PR was simple a wrapper around what you already have - there is no impact whatsoever if you keep using ant, as my intention was not to disrupt anything, but if you (a user, developer, person making an app) can use gradle if they want to. Let me run over some of the benefits of using it over ant:

1) no need to actually install Ant on your local system or keep up with it - the gradle wrapper does that work of installing gradle itself automagically
2) easier set up for a build pipeline. You guys can be using a service like cloudbees or drone.io to auto-build your project on a regular basis, and run unit tests, and tell if someone who is a commiter broke the build and people are automatically notified
3) dependency management - there is no need to package and distribute jars that belong to others - it can pull those off
4) easier for people to develop applications. Using a build pipeline (or manually), or a gradle task, you can publish release jars of ev3classes and DBusJava to a service like Bintray (or maven central, or a LeJos sanctioned Artifactory server on Cloudbees or the like. Users who want to make lejos apps can simple create a project from a template, and gradle will automatically pull in these REMOTE dependencies. They won't need to build, checkout, build sd card, and all that just to develop some simple applications for their project. The plugin in eclipse shouldn't be affected, Eclipse support for Gradle is good.
5) Less cruft and duplication to write in build scripts. If you went all-in (unlike this wrapper approach in my pull request which just extends what you already have) it would eliminate almost all of the Makefiles and shell scripts that are needed.
6) easier to decouple projects that are multi-module. You seem to have no concept of a root projects but just a bunch of individual projects in a source tree, yet some depend on others (like ev3classes and DBusJava. Ideally ev3classes and DBusJava would be part of their own source tree and published independently of the rest of the projects (I understand that is an opinion you may or may not share). Dependencies are clear, and a master project file at the root just helps glue those projects together is all
7) A rich DSL (groovy) to control all aspects of the build - you don't need to make a combo of shell scripts and batch files and maintain those separately, anything you can do in Java (and Groovy) you can do in your gradle.build files. This includes deployment, affect other modules, create dynamic tasks, wrap any Ant call.
8) Better compilation performance. If you are doing a lot of building, Gradle runs a daemon in the background so it's not starting and stopping the jvm over and over - create if you are developing something that requires a lot of rebuilds.
9) full incremental builds
10) better workflow management around the java plugin
11) better support to run tests especially automated ones
12) support for other languages (C/C++, Groovy, Scala, Javascript, of course Java)

More information here: http://www.gradleware.com/resources/tech/java

As I said you guys don't have to use it, I am only trying to help, and I have my own fork to use for my own purposes anyways. I know different OS communities are different about accepting help from outsiders, some more willing than others, some have committes, processes, etc - I can respect that.

Cheers

Ryah
rvanderwerf
Novice
 
Posts: 27
Joined: Thu Mar 13, 2014 5:00 am

Re: Adding Groovy support

Postby Iburong » Fri Apr 18, 2014 9:58 pm

My two cents:

I´ve been working for almost a decade as Java Enterprise developer, and I hate when I´ve to work in something without Maven. Ant can be easy to work with only if people use standard solutions. And they never do. Yes, pom making and mavenizing are not for the faint of heart, but neither is bloated ant configuration.

That said, I find that LeJOS ant files are simple and good configured. And it´s not a good idea to force a building solution upon developers if they are not comfortable with it. I´ve lost countless hours with configurations I did not really understand myself, instead of working on my real problems, so I don´t want the great LeJOS team to lose time and effort on these things if they are not badly needed. Maybe when the project is a stable release they will want to thinker with these new ways of configuring the project if they fancy them.

Of course, I´d prefer not to touch anymore an ant file, I´ve developed some kind of phobia to them :P But LeJOS is so awesome I´ll try to overcome those fears :D Besides, it seems some people on the forums are working with gradle and maven, see the Scratch 2.0 EV3 project, so it´s possible to use them with LeJOS without making them mandatory. Maybe some more examples projects with gradle would be nice?

For me, the ideal would be some way of making the two aproaches to work well together in the same project, but it can get messy to merge and to understand, maybe it´s better to have a normal ant release and a maven-gradle one, better suited for more complicated projects with dependency trees and the like. But the extra work could be too much for the real problems it solves. Maybe the LeJOS team should concentrate in making their solution as good as they can, and then the maven-gradle people could integrate their tech with other third party libraries for a more complex ecosystem.

But, as I said in the first place, those are only my two cents :D
Iburong
New User
 
Posts: 8
Joined: Fri Apr 18, 2014 8:38 pm

Re: Adding Groovy support

Postby rvanderwerf » Tue Apr 22, 2014 5:09 am

Yes mavenizing a project is not fun, nor using one. The only part of maven is really uses is for dependency resolution, (it can use ivy too). One thing that seems a barrier to entry is if a dev wants to use lejos to make a robot, they have to either 1) use eclipse plugin and 2) download and install ant (gradle is self installing and includes ant inside of and 3) for dev to build ev3classes and DBusJava. I went ahead and posted those jars (for .7 haven't build on .8+ yet) on my bintray account, and I can use maven to resolve them.

Attached is a simple Groovy leJOS app with a gradle build file that makes a jar for you, if you open build.gradle you can see how much cleaner it is. There is no need to even have leJos or ant installed or checked out, just run 'gradlew jar' (or gradlew.bat) and you are in business. If you guys decide you want to give it a spin I'll be able to update my PR with the latest version and let me know what options you want 1) full gradle support (I have that files working for DBusJava and ev3classes (they will publish the jars to public bintray like my example uses) or 2) simple wrapper around the existing ant files (Neither requires you to ditch any current ant scripts).

Maybe a good place to start is just build.gradle files for DBusJava and ev3classes(I have those 2 files already made for my project fork) so they can get published to bintray for each release, so people can grab them there.

http://xan-1.xanendeavors.com/EV3GroovyTest.zip

Also some open source projects that use gradle:
Android
Many projects in the Spring IO platform (not just the Spring framework)
Tapestry
Groovy
Griffon
Qi4J
All Netflix open-source projects
Grails
Artifactory
Bintray
Hibernate
Mockito


Cheers

Iburong wrote:My two cents:

I´ve been working for almost a decade as Java Enterprise developer, and I hate when I´ve to work in something without Maven. Ant can be easy to work with only if people use standard solutions. And they never do. Yes, pom making and mavenizing are not for the faint of heart, but neither is bloated ant configuration.

That said, I find that LeJOS ant files are simple and good configured. And it´s not a good idea to force a building solution upon developers if they are not comfortable with it. I´ve lost countless hours with configurations I did not really understand myself, instead of working on my real problems, so I don´t want the great LeJOS team to lose time and effort on these things if they are not badly needed. Maybe when the project is a stable release they will want to thinker with these new ways of configuring the project if they fancy them.

Of course, I´d prefer not to touch anymore an ant file, I´ve developed some kind of phobia to them :P But LeJOS is so awesome I´ll try to overcome those fears :D Besides, it seems some people on the forums are working with gradle and maven, see the Scratch 2.0 EV3 project, so it´s possible to use them with LeJOS without making them mandatory. Maybe some more examples projects with gradle would be nice?

For me, the ideal would be some way of making the two aproaches to work well together in the same project, but it can get messy to merge and to understand, maybe it´s better to have a normal ant release and a maven-gradle one, better suited for more complicated projects with dependency trees and the like. But the extra work could be too much for the real problems it solves. Maybe the LeJOS team should concentrate in making their solution as good as they can, and then the maven-gradle people could integrate their tech with other third party libraries for a more complex ecosystem.

But, as I said in the first place, those are only my two cents :D
rvanderwerf
Novice
 
Posts: 27
Joined: Thu Mar 13, 2014 5:00 am

Re: Adding Groovy support

Postby rvanderwerf » Sat Jul 12, 2014 5:33 am

Just a follow up, I did a workshop in Copenhagen in June, with users using my fork of leJOS with Gradle build script and Groovy support. People had a good time playing with the robots running leJOS and wrote some sample apps in Groovy. Several people wanted to use Groovy to write a simple robot movement DSL I may take a crack at that soon. I used an android phone and Grails to remote control the robot from your PC and see what's going on while you drive it around remotely (a lot cheaper than a lego cam). I'm doing the same workshop July 29, and Minneapolis. I've gotten LEGO Education to even loan us some robot kits, and well as the conference purchase 4 sets for this that they'll probably sell when we're done, as well as Target to give away a retail EV3 set. More info @ http://gr8conf.us if anyone is up that way. You guys have done a great job with leJOS and there definitely is a wider community of people excited about leJOS from the Groovy community!

Here's some pictures from Copenhagen:
https://plus.google.com/photos/+S%C3%B8 ... 5517221313

Links to the slides:
https://github.com/rvanderwerf/webrover ... %20EV3.pdf

Links to webrover grails app source (I changed quite a bit it those to work on EV3)
https://github.com/rvanderwerf/webrover1

Links to my leJOS fork with Groovy and Gradle build (instead of ant):
git://git.code.sf.net/u/ryanv78665/lejos u-ryanv78665-lejos


The tools used to interact: IntellIJ Idea, Gradle, SSH/SCP, Grails. I basically re-shaved the yak and had a pre-prepped microSD card image with everything on it and edimax wifi adapters on the unit. I set up a private hotspot for the robots themselves and the android phones that act as the camera with the IP cam server running on them (Grails app brings them together) using the differential pilot class via rmi. Here's a video of it driving it around my office: http://youtu.be/yxGhA5dOTeQ

Cheers
rvanderwerf
Novice
 
Posts: 27
Joined: Thu Mar 13, 2014 5:00 am

Previous

Return to leJOS EV3 Development

Who is online

Users browsing this forum: No registered users and 1 guest

more stuff