From: James M. <j.m...@ge...> - 2002-05-09 18:02:00
|
At 02:14 PM 5/9/02, you wrote: >Hello all, > >About line length, my proposal is two keep 80 characters when we can, but >tolerate some exceptions. Sun tolerate exceptions in their own code (about >2% of all their lines). I can't win can I :) I'll leave it at 100 for now though. OK, long reply to the issues of package structure follows. Its more a stream of thought and an attempt to get down all the points that just came up in a conversation between Ian and myself. The following can be treated as a proposal, so where I say things like 'x will be droped' or 'y will be renamed z' this is not final its just easier to write it like that. Please excuse the point by point nature of what follows and note that the order is a little random, I have numbered them to make it easier for follow up emails to refer to them: 1) Both of us now agree that Java1.1 is dead. Sun are no longer developing it and the installed user base will do nothing but fall from now on. GeoTools 0.8 will continue to evolve towards a stable 1.0 release and will be targeted directly at Java 1.1. 2) J2ME is a live platform that is fully supported by Sun and it is still being developed. Therefore it makes sense for GeoTools2 to support and target it. 3) There will from this point on therefore be three types of modules. Once which are platform independent and ones which target one or other of the two platforms. 4) defaultcore will be renamed j2secore At this point, j2secore can take advantage of and use whatever aspects of the j2se api it likes. But it must conform with the core interface, which can not take advantage of a full j2se 5) j2me core will be created 6) core will remain known as core and could contain only Interfaces. 7) meta unit tests need to be created for cases where a j2me and a j2se implementation of core interfaces are implemented. i.e. a single unit test built against the interfaces in core will systematicly check that both j2me and j2se implementations work. Following the normal way of working: A bug is spotted in j2secore. A test is added to coreTester to prove that the bug exists j2secore is modified to resolve the bug the unit tests are run and it is noted that j2mecore suffers from the same problem j2mecore is modified to resolve the bug If we do not do this then the separated implementations will drift apart and not remain current. 8) An information file will be added to each module providing at least the following information Module Maintainer Target platform - j2se j2me neutral Required extensions - java3d, Advanced Imaging ... Module dependencies - core, algorithms, ... This can form much of the basis of the jars meta info file. Each module needs a maintainer who understands the module and who can ensure that the extension and dependency requirements are not broken. 9) The default assumption for the availability of resources in GeoTools2 will be the current stable release of JxSE as promoted by Sun at any given time. By default no additional APIs can be considered to be available. Note that modules are free to override this assumption. As noted in 8) above each module can specify a list of required extensions, a 3DLanscape module can therefore require that Java3D be available but I would argue strongly that j2secore should not. 10) Using CVS module capabilities it will be possible for a developer to check-out a subset of the development tree that only contains the modules related to their chosen platform. e.g. cvs co geotools2-j2se geotools-src j2secore j2seAlgorithms java2DRender gmldatasource shapefile gtbuild cvs co geotools2-j2me j2mecore j2meRenderer j2meAlgorithms gmldatasource shapefile gtbuild cvs co geotools2 j2mecore j2meRenderer j2meAlgorithms j2secore j2seAlgorithms java2DRender gmldatasource shapefile gtbuild 11) java2DRenderer needs to stay as java2DRenderer to distinguish itself from PDFRenderer, SVGRenderer 12) platform specific implementations of core interfaces should remain in the same package as the interface. e.g. org.geotools.rendering.java2DRenderer org.geotools.rendering.j2meRenderer Most developers will only be targeting one or the other, and will have checked out modules accordingly so will not see or have access to confusing classes. The unit test can therefore be: org.geotools.rendering.RenderTest And thus have package level access to both Renderers, something which is often very important for unit tests to be able to do. ---------------------------------------- And there is a good place to stop before I get carried away.... (ok, more carried away) If the above makes sense then for each module decisions will have to be made, As an example, should gmldatasource be a j2se module or a common module? Is the overhead of maintaining two gmldatasource implementations worth the benefit of optimizing it for each platform? There are lots of other questions, and I'd guess the above list may raise more issues than it solves, please feel free to be as critical of my comments as you can manage. James (who is catching up in the verbose email stakes...) |