Thanks Mauricio :-) Indeed this proposal is my attempt to get your code and Justin's code code into a similar package structure. Based on Justin's feedback we ended up with the following guideline: > > Of the format org.geotools.SUBJECT.PARSER.SPECIFICATION: > > * SUBJECT - is the *output* being produced (ie style, geometry, > referencing, feature, filter, etc...) > * PARSER - is the kind of "input" being considered (ie text or xml ) > * SPECIFICATION - (optional) if you need to get more specific on > the kind of "input" you can quote the specification here. > > Please note this is for the gory details *only*; your users should not > have to import anything from these packages. You may be stuck making > some of the content public (especially for XML callbacks) - but none > of your example/user code should be forced into an import. > Victor Mauricio Pazos wrote: > Well I am new in this business, and I have not a serious knowledge of general > picture, but the first option inside Justin's comment looks right for me. > > org.geotools.xml.filter.v1_0 > org.geotools.xml.filter.v1_1 > org.geotools.xml.gml.v2 > org.geotools.xml.gml.v3 > > Maybe we need to add version for "org.geotools.filter.text" package, > something > like: > > org.geotools.filter.text.cql.v2_0 > I did not know it was version 2.0.
By using "SPECIFICATION" we would get cql2_0 (I think the goal was to get gml2, gml3, filter1_0 into the package name where people could see it) > > * org.geotools.filter.text.cql2 - parser code for CQL > * org.geotools.geometry.text.wkt - parser code for WKT > * org.geotools.filter.xml.filter1_0 - filter 1.0 bindings > (requires gml2) > * org.geotools.filter.xml.filter1_1 - Filter 1.1 bindings > (requires gml3) > * org.geotools.geometry.xml.gml2 - geometry bindings for latest GML2 > * org.geotools.geometry.xml.gml3 - geometry bindings for latest GML3 > > It would be only a convention, because we only have one implementation > actually. > > By other hand, after our last conversation with Jody about the "best package" > for CQL we move the cql to "org.geotools.text.filter". > > > Is there a mistake in "Description Section"? (swap text and filter) > http://docs.codehaus.org/display/GEOTOOLS/Provide+common+parsers+in+a+consistent+fashion > > > So no there is not a mistake - the motivation is to bring the parser closer to the objects it is producing. > Cheers > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
