Prevent deprecation warnings in documentation
See original GitHub issueThere’s few improvements to be done in Persistent Entity (scaladsl v1.3):
Example code in tests uses scalactic’s ConversionCheckedTripleEquals
which is deprecated in favour of TypeCheckedTripleEquals
.
Issue Analytics
- State:
- Created 7 years ago
- Comments:8 (8 by maintainers)
Top Results From Across the Web
How to ignore deprecation warnings in Python - Stack Overflow
From documentation of the warnings module: #!/usr/bin/env python -W ignore:: ... Disable ALL warnings before running the python application.
Read more >warnings — Warning control — Python 3.11.1 documentation
While within the context manager all warnings will simply be ignored. This allows you to use known-deprecated code without having to see the...
Read more >Disable deprecation warnings in deprecated callables and types
What we want: first check whether bar is deprecated. If so, don't need to check foo. To do that, basically just need to...
Read more >Dealing With Deprecations - GNOME Developer Documentation
One important thing to keep in mind is that 'deprecated' does not mean 'broken', or 'unusable'. There is no need to rush into...
Read more >Enhanced Deprecation - Java - Oracle Help Center
Notifications and Warnings · @SuppressWarnings("deprecation") — Suppresses only the ordinary deprecation warnings. · @SuppressWarnings("removal") — Suppresses ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I just did a sneaky and updated the title to “Prevent deprecation warnings in documentation”, expanding the scope of the issue 😉. This actually just brings it in line with my comment above:
The point is that we don’t want to demonstrate deprecated code in our documentation examples, now or in the future. Both Scala and Java compilers support options to fail on warnings, and we should set those in the documentation build.
@erip fixing warnings in
docs/build.sbt
itself (or anywhere else in the Lagom code base) is always appreciated, but not really the point of this issue.In the case of
LagomApplicationLoader
, this is where deprecated code is used to maintain backwards compatibility, so I think it’s best to leave it alone until the deprecated API is removed in 2.0.The code in question is in
PostSpec
.You can see the deprecation warnings by running:
See also #1282.