Hi all, sorry for the cross-post, this mail talks about a deprecation cleanup work that involves all three projects.
If you have participated to any PSC meeting in the last few months, or read the minutes, you probably know that I've been working on a deprecated API cleanup on all three projects, with the following objectives: - Remove all deprecated API calls, where possible, or suppress the deprecated API call warning, otherwise - Remove all API that has been deprecated over the years, with the exception if APIs that are not yet deprecated in the stable series - Make the build fail if any deprecated API is used (unless explicitly suppressed), thus preventing both careless usage of deprecated API, and easy going deprecation of existing API without a clear replacement strategy The work used all the spare time I could dedicate to coding in the last two months, here are links to the pull requests with some numbers: - GeoTools: https://github.com/geotools/geotools/pull/2309 (161 commits, 1063 modified files, 5000 lines of code modified, 13000 removed) - GeoWebCache: https://github.com/GeoWebCache/geowebcache/pull/747 (32 commits, 102 modified files, 488 lines modified, 400 removed) - GeoServer: https://github.com/geoserver/geoserver/pull/3449 (74 commits, 687 files modified, 2490 lines modified, over 6000 removed) The GeoTools and GeoWebCache PRs are green, the GeoServer one fails because of classes not implementing any longer methods that were deprecated, it should go green once the other two are merged. The PRs are breaking, so merging one of them will cause downstream projects builds to fail, they are meant to be merged together. In terms of mechanics, no new tool has been used, the java compiler itself has been instructed to fail the compile in case of deprecated API usage. In terms of stability of the changes, I did the best I could, but you can see from the numbers of the PRs that this has a been a sizable one man code sprint, so it's unlikely that it won't have any kind of side effect Just like after every other code sprint, I expect some cleanup to follow after merge, once we have the code deployed and running on some server (thankfully GeoSolutions has one server deploying a fresh master nightly build 3 times a day, we should get some early feedback from it soon). Now, there are a few things that I'd need out of you (well, some of you!): - Trying out the 3 builds in a sequence, to double check everything is fine, as Travis cannot provide guarantees for the GeoServer one) - Review and improvements to the PRs (all core devs can commit directly on my branch, anyone else can do PRs) - If you have a project that depends on GeoTools, GeoWebCache or GeoServer, try to build it against the branches and provide feedback (in case of doubt about a missing API, you can check the stable branch and get the same deprecated API direction I used) - Feedback, discussion, concerns? Let me know! Ah... want to know something more about what I've found during the cleanup? Lots, with many things worth cursing about, including: - Deprecated methods/objects with no comment and no replacement - Deprecations in implementation classes but the interface mandates the method without deprecating it - Deprecations pointing to replacement that are also deprecated and with no replacement - Quoting: "@deprecated Replacement to be determined." Seriously? - Deprecating API, providing replacement, and leaving hundreds of calling points in the codebase, losing the best occasion to check if the deprecation and replacement actually make sense (somtimes all you need it to call the replacement method and do a inline refactor) - Deprecated with replacement indications making no sense to a random reader (aka me). Remember to be clear, deprecation is not a reminder to yourself but something affecting users which need to move to a non deprecated approach. - Deprecating object/method because normally it should not be used, but there are some legit cases to do so... just add a comment for it instead of deprecating - Deprecating a method because maybe in the future you will remove it (there were such deprecations 10+ years old, face it, you're not clairvoyant) Once the branches are in, the built-in compile check for deprecations should make people think about the above, clean up after themselves, and stop at least some form of code base littering. Cheers Andrea == GeoServer Professional Services from Andrea Aimethe experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- *Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.*
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
