Building with libraries common amongst projects

[bobwolff68]

Hi all - I'm a mentor for Team 1967 - The Janksters. We've been a C++ team for many years and have flipped to Java this year. I'm looking to either find a solution or recommend a feature. And while I'd love a quick solution, I understand if it isn't something "this year" that gets solved.

At a high level, we have had a few classes which are common year after year. And we also wind up with classes that are common to the current year only but common amongst several projects while the team works on proving out those classes in their "unit test" projects. Working in this manner is pretty crucial to making sure we have code reusability and also that we minimize merge conflicts which keeps the programming and project management for a large programming team "simple."

The problem - the Java build environment WANTS you to put all of your code in /src/main/java// or something like that. But that implies that all of those classes wind up down in the "main robot project". What I want is a way to have these two libraries live "above" the project folders but allow them to be edited and re-compiled as needed (whenever they change).

code/jankyLib/*
code/2022/
code/2022/
code/2022/CommonLibFor2022/*

With the above in mind, each of and should incorporate both the jankyLib/ and also the CommonLibFor2022/ java classes.

Thoughts? I had posed this on Chief Delphi and got some responses about gradle using subprojects or external libraries which seems like the right general answer, but despite doing some reading of gradle, I have yet to figure out how to make this a reality.

In the meantime, I have devised a way to use ln soft/symbolic links on the Mac in order to have each project incorporate those higher / external libraries. But in Windows, it has required copying files and setting them as read-only due to a lack of proper soft links. yeahhh NTFS has soft links but I can't count on all students to have that available. So, it's not a great solution.

If anyone is interested in more of the details of the problem statement and scripts currently, they are in our repo at:

https://github.com/FRCTeam1967/FRCTeam1967/tree/master/code-java/2022/JanksterNewProjectSetup

Building Java Janksters-Style.pdf.pdf

[ThadHouse]

Subprojects really are the only way we'd ever look into maybe supporting, but even then it will always require manual shuffling of code, because we don't support and never will support manually upgrading project files. It will always be a process during the VS Code Import, as we want to be able to change internals between years.

Subprojects are fairly easy to handle by themselves, as long as you don't need wpilib dependencies in the subprojects, but most teams do, and we don't often test that, as its not a common scenario.

But, even using subprojects you don't gain any code separation, other than just changing what the physical root on disk is. You can absolutely have the following folder structure.

src/main/java
-> com/jankster/jankylib (package com.jankster.jankylib, same concept for below)
-> com/jankster/2022common
-> com/jankster/2022
src/test/java
-> com/jankster/jankylib/test
-> com/jankster/2022common/test
-> com/jankster/2022/test

Doing that gains the exact same amount of code separation at least repository wise as subprojects would. Everything is in its own package. The only things you lose are each library in its own separate jar on disk (This doesn't matter, we deploy a fully contained jar anyway), and the ability to run tests on the individual test packages (This is actually easy to solve with 3 custom task definitions, no need for the whole subproject configuration, which I'm happy to help with if you want).

[bobwolff68]

Thanks for the quick reply, Thad.

The folder structure you show has the problem that all of the Jankster code winds up inside the 'current' project. The goal here is to have the jankyLib/ and 2022Common/ codebases reside in folders 'above' or 'equal' to the project itself so that other projects can also utilize those common classes. Otherwise, students using other projects will need to be copying .java files here and there and there will be tons of confusion, bugs, etc.

I'm happy to hear about "custom task definitions" or subproject configs as a better way to accomplish this. And I do realize that this might mean I'm making some small change to the gradlew / gradlew.bat files to support it and that might create upgrade problems in the future for those projects. That's ok by me if that's the cost. I currently am using "source" and "call" in those files to call out to the MacModsScript and WindowsModsScript.bat files respectively.

[ThadHouse]

Doing a quick read through the document, doing something in VS code will never work BTW. The build is entirely handled by gradle, VS Code literally just calls ./gradlew build. Changing things in VS Code will never actually affect the build.

[bobwolff68]

I kinda figured VSCode might be a dead end due to gradle, but thought I'd poke around at the idea. Thanks for nailing this down as an answer to that dead-end. :)