Usage of Gradle instead of Python/Maven mix

[andrii0lomakin]

Good day.
If I understand correctly, you use a mix of Python and Maven because Maven lacks scripting capabilities.
That makes DevOps less user-friendly.

For example, tests that the JUnit plugin could manage in such cases are running by a script that does not provide a summary of test execution very well and needs to be integrated into the CI environments.

If you are interested, I can migrate the main Maven build to Gradle and migrate test scripts so they will be executed inside of Gradle and also provide better compatibility with IntelliJ IDE.

[andrii0lomakin]

Good day, TornadoVM developers.

May I ask you for your opinion ?
Will you accept such PR?

[andrii0lomakin]

Hi @jjfumero
I suppose Gradle could be very useful for compiling and building native libraries as OS-specific dependencies without additional scripting tools.

So, while I am working on other issues, may I ask you to clarify some of your questions?
What do you mean by this question - "If migrated, are you planning to commit to maintaining and support the Gradle build in TornadoVM? This includes builds for Windows, Linux, and OSx.".

I suppose that that unlikely you meant that I or probably other my colleagues should commit to the life-long support of provided Gradle build. It is, BTW, just a Kotlin code, and there are tons of tutorials and docs dedicated to Gradle. So what kind of maintenance do you mean? Could you specify in more detail?

[jjfumero]

The public version of TornadoVM is geared towards academic endeavors and our primary goal is software maintainability with the small research group we have. For enterprise features or LTS we are currently setting up our spin-off company for undertaking the commercial branch of TornadoVM. Hence, all features that are merged (or going to be merged) into the public version of TornadoVM require special care since we can not guarantee that we will have the bandwidth to maintain them. For enterprise requests, we can talk offline.

[andrii0lomakin]

@jjfumero, that is interesting.
I definitely need to discuss that with my colleagues.

[andrii0lomakin]

@jjfumero Follow-up question: Does it mean that the EE version will only be commercially available, and under which license ? We are considering using it in one of our new OS products that we hope will receive coverage of hundreds of thousands of developers, and we can not risk its availability. If, for example, access to the clBlast library will be limited only to the EE version. In such a case, we will have to choose another platform. I prefer to avoid the is as much as possible. But if the open source version is not oriented toward mass production usage or the EE license is restrictive, we will not have any other choice except that.

[andrii0lomakin]

Another question. We assessed that we are able to quickly add support for clBlast and all features we need. Are you open to contributions to the OS version? We think that our developers are professional enough to shape TornadoVM to our needs quickly. Especially if I get it correctly EE version will be closely sourced and we will not have access to code.

[andrii0lomakin]

Hi @jjfumero

The public version of TornadoVM is geared towards academic endeavors and our primary goal is software maintainability with the small research group we have.

I am not sure that I follow. How will the usage of Gradle prevent small academic groups from using TorandoVM ? Let me list the achievements of such migration:

1. Python scripts will be removed from the development workflow, you just use standard build tasks. Please note that I mean development workflow, not usage workflow, till the requirement to register GraalVM as JIT is present, and there are no jars with binaries for specified OS+backend tornado python script still will be used.
2. All tests will be executed using standard tools, which will shorten the development lifecycle and automatically integrate with all CI tools, increasing project code quality.
3. You do not even need to install Gradle. It has its own script wrapper provided.
4. There are tons of tutorials that allow users to start to work with Gradle in 5 min.

Could you provide me examples of how the usage of Gradle will prevent the academic community from working with TornadoVM?

[jjfumero]

I am not against Gradle by any means and I did not say Gradle prevent academics to work with TornadoVM. I am trying to see the benefits of transition to such systems. Besides, since it is a tool we are not used to, I want to check that, if there is an issue (OS updated, new binaries, broken links, etc.), we still can contact you, or the person that contributes to this change, to provide answers. From my view and my understanding of 15+ years working on Open Source projects, this is a very reasonable question to ask.

To move forward, from my understanding, this is your proposal:

1. Gradle will be used to build the TornadoVM project from source. This includes the all JNI-native libraries and the SDK (config FPGA files, examples, etc), with the end goal of facilitating builds within IntelliJ and avoid the Python script.
2. Gradle will facilitate the report of testing and integration with CI tooling.
3. Python scripts still will be used to launch/deploy TornadoVM from command line (tornado, tornado-test scripts).

Is this correct? If so I will discuss this internally.

[andrii0lomakin]

Hi @jjfumero
No. That is not correct summary.
I will provide clarifications tomorrow.