Directory structure for non-java projects


(Roman H) #1

I plan to use Gradle for some non-java legacy projects that we have, the project I am working on now has some C and perl code as well as shell scripts. It also has some artifacts like txt, pdf and xls files. Project also has SQL scripts.

What happens in the project is I read txt file that is generated from Excel, generate some C code and some SQL, compile the C code (right now it’s done by calling external script) then call something to modify the DB using the generated SQL.

So, here is my question: is there a preferred way to make a directory structure to make it easier in the future to make build scripts?

I found this for maven: http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html but it doesn’t have much on languages other then Java, it has src/main/scripts where I guess I could put my perl, shell and SQL.

Some of the files are generated during the build, so they should probably not reside in the same place as the non-generated scripts.


(Sion Williams) #2

I guess languages that predate java can still adopt some of its practices. In your example you could use something like the following:

build docs lib src/c src/sql src/test tools

Gradle will not impose any restrictions on the way you want to work either.


(René Groeschke) #3

I agree with Sion, For some languages, there are conventions in gradle (like java, scala, groovy and now also for c and c++) but you seem to have a broader technology stack.

By introducing your own convention (like sion suggests), you can leverage your build with your own language plugins that follow those conventions. For your developers, it’s quite easy then. They just need to apply your plugins plugin and get the convention out of the box.

cheers, René