We have not had the policy of deprecating unsupported modules; but I could see the point of deprecating modules that are on their way out because a replacement is ready.
Due to our plugin system there is not much opportunity for code to depend directly and thus see deprecation warnings. Ideas: - we could place a warning in the log when a new instance is actually created for use? Jody On Thu, Sep 2, 2010 at 10:21 PM, Mª®k <[email protected]> wrote: > 2010/8/31 Jody Garnett <[email protected]>: >> I remember us having this discussion earlier in the year; I will go ahead >> and move those two over. >> Jody >> >> On 31/08/2010, at 5:25 PM, Jody Garnett wrote: >> >>> I am writing up some docs (actually listing the formats supported by >>> geoserver) and decided to go back to the source code to look. Is there >>> a list of formats somewhere else that I should of found? >>> >>> A couple of questions about plugins on trunk: >>> plugins/db2 (is this being moved to unsupported?) >>> plugins/postgis (is this being moved to unsupported?) >>> plugins/jdbc/jdbc-postgis >>> plugins/jdbc/jdbc-db2 > > can/will they (the packages) be marked as deprecated as well? I am > guessing the <jdbc-> versions are replacements...? > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
