# Adding support for new non-JVM language

**URL:** <https://discuss.gradle.org/t/adding-support-for-new-non-jvm-language/6936>\
**Category:** Old Forum Archive\
**Created:** [September 6, 2014, 6:20pm UTC](https://discuss.gradle.org/t/adding-support-for-new-non-jvm-language/6936 "2014-09-06T18:20:00Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Schalk\_Cronje](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/schalk_cronje/32/6511_2.png) [@Schalk\_Cronje](https://discuss.gradle.org/u/Schalk_Cronje)\
**Post date:** [September 6, 2014, 6:20pm UTC](https://discuss.gradle.org/t/adding-support-for-new-non-jvm-language/6936/1 "2014-09-06T18:20:00Z")

</div>

What is the best place to look for examples to implement a SourceSet for a non-JVM language? The Scala/Clojure/Groovy source sets all build off the Java source sets, which are not quite appropriate. The C/C++ source sets seem to do a lot more than required and are all dependent on internal Gradle classes.

Any other examples I could look at? Or at least some pointers on what I would for an implementation would be appreciated

---

<div class="post-metadata">

**Author:** ![Ray\_Tayek](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/ray_tayek/32/4985_2.png) [@Ray\_Tayek](https://discuss.gradle.org/u/Ray_Tayek)\
**Post date:** [September 7, 2014, 5:53am UTC](https://discuss.gradle.org/t/adding-support-for-new-non-jvm-language/6936/2 "2014-09-07T05:53:00Z")

</div>

maybe look at the cpp plugin?

---

<div class="post-metadata">

**Author:** ![Schalk\_Cronje](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/schalk_cronje/32/6511_2.png) [@Schalk\_Cronje](https://discuss.gradle.org/u/Schalk_Cronje)\
**Post date:** [September 8, 2014, 6:14pm UTC](https://discuss.gradle.org/t/adding-support-for-new-non-jvm-language/6936/3 "2014-09-08T18:14:00Z")

</div>

The native set (c,cpp,asm) is too complex an implementation to use as an archetype for many other languages.

---

<div class="post-metadata">

**Author:** ![Peter\_Niederwieser](https://avatars.discourse-cdn.com/v4/letter/p/9f8e36/32.png) [@Peter\_Niederwieser](https://discuss.gradle.org/u/Peter_Niederwieser)\
**Post date:** [September 9, 2014, 2:39am UTC](https://discuss.gradle.org/t/adding-support-for-new-non-jvm-language/6936/4 "2014-09-09T02:39:00Z")

</div>

The new source sets are the way forward not only for cpp, but also for the new jvm plugins as well as most other languages. And unless your source sets need additional properties, you don’t need to implement your own types anymore. Just be aware that the API is still incubating and breaking changes are possible.

---

<div class="post-metadata">

**Author:** ![Schalk\_Cronje](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/schalk_cronje/32/6511_2.png) [@Schalk\_Cronje](https://discuss.gradle.org/u/Schalk_Cronje)\
**Post date:** [September 13, 2014, 8:27pm UTC](https://discuss.gradle.org/t/adding-support-for-new-non-jvm-language/6936/5 "2014-09-13T20:27:00Z")

</div>

Peter, I am still nto quite clear how I would go about to do something for arbiitrary language ‘Foo’ which might require it’s files to be in ‘src/foo’, ‘src/foo/test’, ‘src/foo/docs’.

_Note_: I have specifically chosen a layout which does not match with any of the existing languages supported by Gradle.

---

<div class="post-metadata">

**Author:** ![daz](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/daz/32/2475_2.png) [@daz](https://discuss.gradle.org/u/daz)\
**Post date:** [September 16, 2014, 2:43am UTC](https://discuss.gradle.org/t/adding-support-for-new-non-jvm-language/6936/6 "2014-09-16T02:43:00Z")

</div>

We’re actively working on making it easier to add support for a new language. This will be based on the current native language plugin implementations, as well as the the new ‘java-lang’ and ‘jvm-components’ plugins. Following this pattern is the way to go, although a lot of changes are planned in this area to make this a lot simpler.  
  
What is the target platform/runtime for the language you want to support: the ‘native’ © runtime? the JVM? a Javascript interpreter? Something else?

---

<div class="post-metadata">

**Author:** ![Schalk\_Cronje](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/schalk_cronje/32/6511_2.png) [@Schalk\_Cronje](https://discuss.gradle.org/u/Schalk_Cronje)\
**Post date:** [September 16, 2014, 8:43am UTC](https://discuss.gradle.org/t/adding-support-for-new-non-jvm-language/6936/7 "2014-09-16T08:43:00Z")

</div>

I have pretty coy about this to date as I wanted to experiment first. However, I will mention at this point that I have been looking at Ruby. Some people might now that I have been involved with the line of [jruby-gradle plugins](https://github.com/jruby-gradle) of late.

One fo the things we are looking at is to call Rake (via JRuby) from Gradle. When using Rake there is a conventional file layout, more or less as below

```gradle
lib
bin
data
doc
spec
 test

```

At this point I don’t think the tests can be spit away in the same way as we are used to for other (maybe it can, but I am not a Rake expert).

As a start I thought that maybe it could be hosted below ‘src/ruby’ and I have come up with the below Gradle psuedo-code

```gradle
sources {
    main {
        ruby {
            source {
                srcDirs "src/ruby/lib"
                include "**/*.rb"
            }
            bin {
                 srcDirs "src/ruby/bin"
            }
            data {
                srcDirs "src/ruby/data"
            }
            doc {
                srcDirs "src/ruby/doc"
           }
           spec {
                srcDirs "src/ruby/spec"
           }
       }
   }
      test {
     ruby {
         source {
            srcDirs "src/ruby/test"
            include "**/*.rb"
         }
    }
}

```

**WARNNG** : it is really just a concept, nothing more, at this point in time.

Hopefully this will give you more of an idea.