Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for vendordep annotation processors #643

Open
jwbonner opened this issue Jan 16, 2023 · 3 comments
Open

Support for vendordep annotation processors #643

jwbonner opened this issue Jan 16, 2023 · 3 comments

Comments

@jwbonner
Copy link
Member

Allowing for annotation processors in the vendordep JSON in addition to normal Java dependencies would make it easier to install/update libraries that rely on them. Currently, the best solution is to include the annotation processor manually in build.gradle, which isn't kept up to date with the rest of the vendordep.

@sciencewhiz
Copy link
Contributor

I suspect this would be a fairly significant change to gradlerio.

Have you considered parsing the vendordep with gradle to extract a version and use that in the build.gradle, since advantage kit already ships a build.gradle?

@jwbonner
Copy link
Member Author

Thanks for the suggestion. Parsing the vendordep seems to be a decent if messy solution, so we start suggesting that in the future. In general, we still want to make installing AdvantageKit into existing projects as seamless as possible by reducing the number of changes required beyond the vendordep. I'll maintain that this seems like a reasonable feature for GradleRIO to support natively given the increasing use of vendordeps for general libraries, but I definitely have limited insight into how significant a change it would be.

@ThadHouse
Copy link
Member

I don't think adding features like annotation processing would be that worth it. Once things get that complicated, adding things like that would be much better done through the DSL. We only did the vendor dep jsons because there was no standard way in gradle to do C++ or JNI dependencies. For standard libraries, we'd really prefer to not reinvent the wheel and just use standard gradle things.

Also,

configurations.all {
    exclude group: "edu.wpi.first.wpilibj"
}

Would likely never reach the bar to be allowable in a vendor dep.

Instead of adding to vendor deps, gradle can actually apply arbitrary .gradle files. We could update the vendor dep infrastructure in gradle to allow configuring from the gradlerio dsl, instead of just json. Then you could just provide an advantagescope.gradle, have users apply that from their build.gradle file with apply from: 'advantagescope.gradle'. That gradle file could do everything. Block the wpilib configuration, set up the repositories, and all the extra dependencies necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants