-
Notifications
You must be signed in to change notification settings - Fork 70
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
Comments
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? |
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. |
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,
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 |
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.
The text was updated successfully, but these errors were encountered: