chore: move src folder to subproject

[eddumelendez]

It also supports ConnectionDetails for upcoming Testcontainers and Docker Compose service connection support.

[hello-caleb]

Thank you for this contribution! Our apologies for the delay in reviewing your PR. As maintainers, we are working hard to cover as much as we can, and the assistance of the community is always deeply appreciated!

While the code looks sound, I would also advise updating the README.md file to note the new structure. You can find this referenced in the OpenFGA Contribution Guidelines.

Others may have some questions to confirm that the build process works end-to-end locally with the new subproject structure, given the upcoming Testcontainers and Docker Compose service connection support. But my main comment is the request for a PR for documentation updates and linking that PR to this one in this PR's description.

[jimmyjames]

Thanks @eddumelendez! Also apologies for the extended delay here 😞.

I love this change, and its a structure I had originally envisioned, but I wonder if it will run into the same issue with nexus publishing that we encountered before? We originally envisioned a structure similar to what you have done here, but had issues with nexus publishing that didn't appear to have a nice solution (though it has been some time since then and I see the issue has many comments).

[piotrooo]

This PR LGTM ❤️

I'm just curious if naming the project spring-boot-starter is the best choice, considering it will include Testcontainers and Docker modules. Just sharing my thoughts 🤔, not saying it's wrong.

Maybe just spring-boot would be enough.

[rhamzeh]

@eddumelendez - thanks for this PR! We're not ignoring it, we'd just like to test it with the release process taking into account what @jimmyjames has mentioned above. Do expect this to take some time as we have a few other priorities, but we'll be investigating once we're back from the holidays, so expect an approval or a clearer feedback in the first few weeks of 2025

[curfew-marathon]

This PR has had no human activity for 90 days, so it has been marked lifecycle/stale.

This is automated backlog grooming, not a judgment on the work.

What happens next, unless there is activity:

• In 30 days, it will move to lifecycle/closing-soon
• 30 days after that, it will be closed

To keep it open, push a commit or leave a comment, and the clock will reset. For work that should not auto-close, such as an RFC or long-running experiment, ask a maintainer to add lifecycle/frozen.

[curfew-marathon]

This PR has had no human activity for 30 days since being marked lifecycle/stale, so it has now been marked lifecycle/closing-soon.

It will be closed in 30 days unless there is new activity.

If the work still matters, this is the moment to say so: leave a comment, push a commit, or ask a maintainer to add lifecycle/frozen if it should be kept open long-term.

If this work is no longer being pursued, no action is needed.