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
Unnecessary-looking dependencies #2824
Comments
The goal here was to fix #2721. Evidently "compile-only" doesn't actually make the annotations available at compile time to projects that compile against Guava, and that causes problems for people who compile with all warnings as errors. But if making the dependencies required at runtime causes problems, too, we'll have to figure out what to do. Are they causing problems for you, or is it just surprising that we made this change? |
In case you didn't know "compile-only" is the Sounds like they should be either |
They used to be |
I believe |
Any chance of a quick 22.1 release to resolve this? Otherwise we'll be adding a ton of exclusions for dependency convergence. |
I just tested with I'll put something in the release notes. We should think more about whether dependency version bumps should show up in the release notes in general. |
https://github.com/google/guava/wiki/Release22#additional-changes That may be all we can do, but if anyone has other ideas, I'm all ears. Sorry for the trouble. |
Then my third suggestion still remains - move them to be dependencies of a new artifact.
|
Ah, sorry, I'd missed that one. I think I feel better with the current version, which requires action from people who use dependency convergence (and who presumably understand the problem and how to fix it), than with the proposed alternative, which requires action from people who are turning on warnings or using annotation processors (who might see a variety of different errors and might not know how to debug them). I know that that's still a bad experience for you; it just seems like it has to be a bad experience for someone for all the reasons to diamond dependencies normally are a bad experience :( |
Will Guava version |
/cc @cgdecker re. 23.0-rc1 concern |
@cpovirk's conclusion above seems to have been that of the two options we have, both of which cause issues for some people in some way, we should stick with what we're currently doing. So 23.0 will continue to have those dependencies as non-optional. |
This is madness |
The JUnit 5 team have gone and made their dependency on opentest4j (another annotations library) Maybe it goes to show that annotations aren't really as optional as we all might think? |
I'm dealing with it by using |
@jbduncan , thanks for the link to the JUnit 5 change. I mentioned it on the Maven feature request for a true compile-time scope. |
…loading and revered to WEB-INF/classes/molgenis.properties feat(Jenkinsfile): added for building development war for Docker production fix(MolGEnisWebappSecurity.java) disabled hsts in webapp, you can set this enabled when you do not run this application on apache and offload ssl on it chore(travis.yml): disabled travis build fix(Jenkinsfile): add Jenkins build fix(molgenis.home): get this setting from the system environment instead of contained JVM environment chore(Jenkinsfile): updated scp flow to download server feat(Jenkinsfile): updated to run tests and publish to sonatype fix(Jenkinsfile): removed failure block fix(Jenkinsfile): removed publish block fix(Jenkinsfile): removed post block fix(Jenkinsfile): set JAVA_HOME and PATH fix(Jenkinsfile): set JAVA_HOME and PATH fix(Jenkinsfile): set JAVA_HOME and PATH fix(Jenkinsfile): set JAVA_HOME and PATH fix(Jenkinsfile): set JAVA_HOME and PATH fix(agent): updated agent to maven fix(jdk): upgraded to Oracle fix(agent): fix syntax jenkinsfile fix(agent): can not address node directly updated build config fix(codecov) bash script fix(codecov): you need to do a different call to codecov in jenkinsfile Updated build config according to sonaytype jenkins plugin import github comment github out upgraded yarn for efficiency reasons add sonar token in credentials plugin update node version for performace reasons updated sonar build updated build config for build trigger updated version number Added codecov token fix(jenkinsfile): closure of unit block fix(jenkinsfile): closure of unit block feat(Dockerfile): add Dockerfile fix(Jenkinsfile): added build stage fix(Jenkinsfile): ignore docker validate date before saving WIP fix autosave; pass state and data as payload and determine updatedField before committing the update fix(actions): updated next tick configuration fix(actions.spec.js): test in actions fix eslint warning ignore unused expression eslint warning in e2e spec Only validate changed field before auto save + split auto save action into validate action and save action fix(index.js): removed proxytable because of failing e2e tests url-encode api calls Exclude compile scope annotation dependencies from guava. See google/guava#2824 (molgenis#7362) Fix molgenis#7365 Range type mismatch unclear error feat(docker): add building a docker image feat(docker): add building a docker image feat(docker): add building a docker image fix(sonar): quiet mode off fix(sonar): quiet mode off updated docker config and module deletion for sonar Try to sign in release Move pgp and nexus plugins out of release profile deploy before publish Fix sonar build step, run differently for PRs. Fiddle fiddle. Use different oauth token for github PR comments. Merge build/test/deploy steps, doesn't look like they're saving time. Provide settings xml to deploy task Move Dockerfile to molgenis/app dir Deploy to sonatype snapshot and docker hub. Add milestone Pick up versioning scheme from jx Use kubernetes agent. Try a complete build in the docker maven image, to see what happens Don't skip js build Redirect test output to file Don't build docker image in the molgenis-app project yet. Mount host docker socket and executable in maven container as a volume. Build docker image and push it. Switch to custom molgenis-maven docker image that already contains the docker executable Try different registry Move pod template to the Jenkins configuration. Change container label. Publish to registry.molgenis.org Run tests as well Fiddle with the jenkinsfile Run codecov in alpine container Deploy only the image, leave jar files that noone depends upon out of the maven repo Docker build, tag, push, all in the package phase Try to fix codecov script Remove leftover dockerfile target from parent pom Ditch the codecov debug flag Prefix PR tag with PR- Reinstate Prepare step, codecov needs to know GIT_COMMIT. Update pod and container names Add integration tests Explicitly push docker snapshot, and remove the push from package phase. rename pod label default -> molgenis skip unit test result collection add sonar support added docker-compose set right Dockerfile options updated documentation Fix syntax of Jenkinsfile
compile time additional artifact and (sic!) a weird empty artifact. Excluding compile-time only dependencies as per google/guava#2824
I was going to say that this also paves the way for including the annotation as a non-optional dependency, should we wish to follow our Guava precedent for annotations: - google/guava#2824 - google/guava#2721 But I see that it's retention=SOURCE anyway, so there isn't much reason to do that -- except maybe consistency with other annotation packages someday. (Maybe it's still a negative then, as it might still let people rely on our transitive dependency?) I think the relationship of all this to Java 11 was that I might have to set an Automatic-Module-Name on AutoService, and it makes more sense to set it after we've done the processor-vs.-annotation artifact split. Once I was upgrading, it made sense to set up the annotation processor the Right Away, now that we're using a version in which that works. (Or maybe it always worked but now it's nice that it gets the processor off the classpath?) Or maybe there was some other reason for the change to the annotation-processor setup; once again, I forget. It looks like it might have been that AutoService stops running when I switch how we run Error Prone. Hopefully this was the solution :) But it's probably a good idea in any case. This CL is basically following the "alternatively" instructions in https://github.com/google/auto/blob/master/value/userguide/index.md#in-pomxml ...even though the AutoService instructions haven't been similarly updated yet: https://github.com/google/auto/tree/master/service#download ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=272720556
I was going to say that this also paves the way for including the annotation as a non-optional dependency, should we wish to follow our Guava precedent for annotations: - google/guava#2824 - google/guava#2721 But I see that it's retention=SOURCE anyway, so there isn't much reason to do that -- except maybe consistency with other annotation packages someday. (Maybe it's still a negative then, as it might still let people rely on our transitive dependency?) I think the relationship of all this to Java 11 was that I might have to set an Automatic-Module-Name on AutoService, and it makes more sense to set it after we've done the processor-vs.-annotation artifact split. Once I was upgrading, it made sense to set up the annotation processor the Right Away, now that we're using a version in which that works. (Or maybe it always worked but now it's nice that it gets the processor off the classpath?) Or maybe there was some other reason for the change to the annotation-processor setup; once again, I forget. It looks like it might have been that AutoService stops running when I switch how we run Error Prone. Hopefully this was the solution :) But it's probably a good idea in any case. This CL is basically following the "alternatively" instructions in https://github.com/google/auto/blob/master/value/userguide/index.md#in-pomxml ...even though the AutoService instructions haven't been similarly updated yet: https://github.com/google/auto/tree/master/service#download ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=272720556
Copy-paste exclusions for future readers...
|
@davidljuba15031979 |
@guidomedina maybe they should be |
I don't think they are going to change it, we will have to live with the long exclusion list. |
I am surprised this hasn't been dealt with properly at this time. We use Guava in a lot of our projects and have a bunch of custom build code just dealing with excluding all the compile-time stuff from our runtime and distributions. It's a huge hassle to deal with this and there are no other projects doing something like this. Really hope this will all be reverted. |
There is a very old comment regarding splitting and moving the annotations classes to Then probably making such Initially there were only 4 extra dependencies but now there are 6 already which has been becoming more and more of a hassle. It would make the dependencies tree look like this (notice the
|
I see. The previous post had suggested that the The idea of a non-
For that reason, I'm still not sure that a change is a net win. In better news:
|
@cpovirk I would say it is fine as a normal dependency ( |
Still unsure, and keeping this on the back burner, but that's the best alternative I've heard so far. Call it "guava-optional-at-runtime-deps" or something. Also, I was confused about j2objc: We use more annotations than just J2ObjCIncompatible. I had briefly hoped that we could continue to use the j2objc artifact but make it provided or optional, since J2ObjCIncompatible has source retention. But other annotations that we use from the artifact have class retention. |
@cpovirk this is a well known used pattern by other projects, when an API starts getting cluttered by "non-related" things or cover several groups then each group is put into a smaller artifact specialized in doing a single group of things, annotations is a good example, for example the famous Jackson dependencies have:
This also applies to many other projects which do exactly this same split process; cluttering an API without clear division/delegation of responsibilities has a negative effect; I will tell you what I think before I decide to include Guava in my projects:
Please don't take my thought process wrong; this is what the mind does and denying it would be hypocritical on my side, a good example of this would be to split Guava into:
Of course; in due time, |
I hope someone still pays attention to an issue that has been inactive for three years now. Otherwise I threaten you with opening a new one!
Despite simplifying dependency exclusion, this would also help with #2970, since |
New in Release 22 are a bunch of Maven dependencies that look like they should be compile-only, but are now required at runtime.
The text was updated successfully, but these errors were encountered: