Porting Lucene: Iteration 1 – Project Setup

So I thought project setup would be the easiest item to complete. Turns out the due diligence was far greater than I thought. Why? In short there are tools that have best practices for a project built in like Gradle or Cargo. However they just didn’t quite fit what I needed. Letls look at those use-cases.

Little to no setup required

This is something I feel very strongly about. This project should make contributing absolutely frictionless. You should not need a specific IDE or require changing versions of system libraries.

Don’t introduce yet another language if you don’t have to

Choosing the best tool for a task is important. However there is a certain amount of overhead with each language. Some require additional tooling and may not be widely known. So reusing languages that are used elsewhere in the project is preferable. 

Option #1: Gradle

This should be a no brainer. Lucene uses Gradle. I’m porting Lucene. I should use Gradle. However while I am porting Lucene to learn I want to make this easy for others to adopt. Gradle brings in either Groovy or Kotlin.

Option #2: Cargo

Cargo is the Rust package manager. Cargo downloads your Rust package‘s dependencies, compiles your packages, makes distributable packages, and uploads them to crates.io, the Rust community’s package registry

OK… That I stole from Cargo’s guide. Cargo is going to be needed for building/managing the rust components. However we really need a level of orchestration above it.

Option #3: Maven

Maven for the longest time was the work horse for most Java development. Unlike Gradle Maven can be done using xml exclusively. This then becomes a discussion of project management via configuration or code. Both have their time/place. As a project becomes increasingly complex code becomes preferable over configuration.

Option #4: Make

There is something to be said for keeping it simple. Make is typically included in every distribution and shell scripting provides the capabilities I need. While shell scripting is yet another language it is already pulled in by Docker. This makes the most sense.


A mixture of Option #2, #3, & #4 seems like the best course. Due to the expected complexity of the project Make seems like the best option as it has the least amount of dependencies. Maven & Cargo can then be used for Java & Rust sub-components respectively.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s