magmaOffenburg / RoboViz

Monitor and visualization tool for the RoboCup 3D Soccer Simulation League
Apache License 2.0
52 stars 17 forks source link

Migrate to gradle and update jogl to version 2.3.2 #106

Closed Seil0 closed 4 years ago

Seil0 commented 4 years ago

This pull request migrates RoboViz to gradle as a build system and updates jogl to version 2.3.2. Gradle brings the advantages of a modern build system, while still making it easy for users to install RoboViz via the old install scripts. The update of jogl should fix the Exception on Mac-OS as mentioned in #93.

To install RoboViz simply use the install script. It's also possible to use gradlew shadowJar and copy all needed files, including the RoboViz jar into the install directory. To run RoboViz simply use gradlew run. Note, for Windows use gradlew, for unix systems use ./gradlew

This pull request is still WIP, since there are some minor things missing:

Seil0 commented 4 years ago

@Gama11 @klausdorer this pr is no longer WIP. Could you please have a look and test these changes on your systems?

Gama11 commented 4 years ago

First off, thanks for doing this! :)

I love how much cleaner the resulting bin folder is - just a single .jar file that contains everything. Is there even really a difference between building for Windows and Linux at this point (apart from sh vs bat)? I see that RoboViz.jar\natives\ contains native dependencies for all sorts of different platforms. Does that mean the same .jar would also work on Linux, even if built via bat-build.bat?

Speaking of the build scripts, I think we can just name those build.bat and build.sh now.

Is there a reason to put gradlew / gradlew.bat into the root directory / is that the convention? Otherwise, scripts/ might be more fitting?

Speaking of the root directory, is there a point to having the things related to Maven publishing in the root build.gradle? I'm assuming there's not a lot of point to publishing something like RoboViz on Maven, since it's not a library?

I'm not sure that client is the best name for the subproject that contains the actual RoboViz sources. I'm guessing you had to choose a different name because the root project is already called "RoboViz"?

I'm not sure you've properly merged all the latest changes from the dev branch. For instance, I'm missing the Ctrl+C shortcut for the "Connect to..." menu item. and the popup also still uses the old UI.

Seil0 commented 4 years ago

I see that RoboViz.jar\natives\ contains native dependencies for all sorts of different platforms. Does that mean the same .jar would also work on Linux, even if built via bat-build.bat?

That's correct, I just kept the Linux/Unix and Windows install scripts so that users don't need to use gardle and can use the "old" install scripts.

Is there a reason to put gradlew / gradlew.bat into the root directory / is that the convention? Otherwise, scripts/ might be more fitting?

Gradle usually want the files there, it's the default gradle setup

Speaking of the root directory, is there a point to having the things related to Maven publishing in the root build.gradle? I'm assuming there's not a lot of point to publishing something like RoboViz on Maven, since it's not a library?

That's just a leftover, my bad.

I'm guessing you had to choose a different name because the root project is already called "RoboViz"?

Yes, i think we could use a more fitting name.

I'm not sure you've properly merged all the latest changes from the dev branch. For instance, I'm missing the Ctrl+C shortcut for the "Connect to..." menu item. and the popup also still uses the old UI.

I'll have a look at it.

Gama11 commented 4 years ago

That's correct, I just kept the Linux/Unix and Windows install scripts so that users don't need to use gardle and can use the "old" install scripts.

I wonder if we should simply have build.sh and build.bat produce the exact same output then (i.e. copy the scripts needed for all platforms: roboviz.bat, roboviz.sh...). Then the same build runs everywhere, and we don't need to think about setting up a separate CI job that runs on Windows to obtain a Windows binary for https://github.com/magmaOffenburg/RoboViz/releases.

Seil0 commented 4 years ago

I wonder if we should simply have build.sh and build.bat produce the exact same output then (i.e. copy the scripts needed for all platforms: roboviz.bat, roboviz.sh...). Then the same build runs everywhere, and we don't need to think about setting up a separate CI job that runs on Windows to obtain a Windows binary for https://github.com/magmaOffenburg/RoboViz/releases.

That sounds good to me.

I'm not sure you've properly merged all the latest changes from the dev branch. For instance, I'm missing the Ctrl+C shortcut for the "Connect to..." menu item. and the popup also still uses the old UI.

I think while rebasing i only merged files changed in 8df4e8c. I'll resolve the missing commits by hand then.