I think that's a good idea. Currently you have to guess which of the 3 WFSConfiguration your code is referring to unless you look in the imports.
Ian On Sun, 28 Oct 2018 at 17:35, Jody Garnett <jody.garn...@gmail.com> wrote: > I think we should rename that back as I do not want to disrupt client code > (those configuration objects are one of the few points of contact client > code uses). > > That said I like the explicit naming - is it worth having the explicit > naming and extending a deprecated Configuration class for exsisting client > code? Just to improve readability... > > On Sun, Oct 28, 2018 at 2:22 AM Ian Turton <ijtur...@gmail.com> wrote: > >> Yes, I did - it was causing a compile error in eclipse, but I suspect >> that was a corrupt or out of date jar thing. So it could be reverted. >> >> I'm running the 2.15.0v20180723 version of the EMF base runtime, and >> apparently 2.14.0.v20180706 of the EMF code generation - both are what >> update considers the latest version on Ubuntu. >> >> Ian >> >> On Sun, 28 Oct 2018 at 08:04, Jody Garnett <jody.garn...@gmail.com> >> wrote: >> >>> So just to confirm you did rename WFSConfiguration_1_0.java by hand :) >>> >>> Any idea about my inability to open the genmodel files? Can I confirm >>> what version we are using or something. I did install 18.9 (4.9.0) eclipse >>> modeling distribution, what are you using? >>> >>> On Sat, Oct 27, 2018 at 1:28 AM Ian Turton <ijtur...@gmail.com> wrote: >>> >>>> I'd completely forgotten (or erased from my memory) about the code-gen >>>> stuff. >>>> >>>> Ian >>>> >>>> >>>> On Sat, 27 Oct 2018 at 02:41, Jody Garnett <jody.garn...@gmail.com> >>>> wrote: >>>> >>>>> I have been trying to chase this down, unable to open wfs.genmodel: >>>>> >>>>> Problems encountered in the model >>>>>> This ExtendedMetadata annotation detail with the key 'affiliation' >>>>>> contains a bad value >>>>>> The affiliation reference ' >>>>>> http://www.opengis.net/gml#_FeatureCollection' does not resolve to >>>>>> an Ecore structure feature >>>>> >>>>> >>>>> Also looking at the xsd modules, shows some of the binding code was >>>>> generated, but I cannot find out from here (this code needs to change from >>>>> org.geotools.xml --> org.geotools.xsd to avoid split packages). >>>>> >>>>> Ian asked about XML Binding Generation Apr 2017, but it focused >>>>> largely on object generation (to parse data into) rather that how bindings >>>>> are generation. >>>>> >>>>> Kevin pointed me towards our xml-codegen plugin (thanks Kevin) which >>>>> is configured at the end of the pom.xml: >>>>> >>>>> <plugin> >>>>> <groupId>org.geotools.maven</groupId> >>>>> <artifactId>xmlcodegen</artifactId> >>>>> <version>${project.version}</version> >>>>> <configuration> >>>>> <schemaLocation>wfs.xsd</schemaLocation> >>>>> >>>>> <schemaSourceDirectory>${basedir}/src/main/resources/org/geotools/wfs/v2_0</schemaSourceDirectory> >>>>> <schemaLookupDirectories> >>>>> >>>>> <schemaLookupDirectory>${basedir}/../xsd-core/src/main/resources/org/geotools/xml</schemaLookupDirectory> >>>>> >>>>> <schemaLookupDirectory>${basedir}/../xsd-core/src/main/resources/org/geotools/xlink</schemaLookupDirectory> >>>>> >>>>> <schemaLookupDirectory>${basedir}/../xsd-fes/src/main/resources/org/geotools/filter/v2_0</schemaLookupDirectory> >>>>> >>>>> <schemaLookupDirectory>${basedir}/../xsd-ows/src/main/resources/org/geotools/ows/v1_1</schemaLookupDirectory> >>>>> >>>>> <schemaLookupDirectory>${basedir}/../xsd-gml3/src/main/resources/org/geotools/gml3/v3_2</schemaLookupDirectory> >>>>> >>>>> <schemaLookupDirectory>${basedir}/../xsd-gml3/src/main/resources/org/geotools/gml3/v3_2/gco</schemaLookupDirectory> >>>>> >>>>> <schemaLookupDirectory>${basedir}/../xsd-gml3/src/main/resources/org/geotools/gml3/v3_2/gmd</schemaLookupDirectory> >>>>> >>>>> <schemaLookupDirectory>${basedir}/../xsd-gml3/src/main/resources/org/geotools/gml3/v3_2/gmx</schemaLookupDirectory> >>>>> >>>>> <schemaLookupDirectory>${basedir}/../xsd-gml3/src/main/resources/org/geotools/gml3/v3_2/gsr</schemaLookupDirectory> >>>>> >>>>> <schemaLookupDirectory>${basedir}/../xsd-gml3/src/main/resources/org/geotools/gml3/v3_2/gss</schemaLookupDirectory> >>>>> >>>>> <schemaLookupDirectory>${basedir}/../xsd-gml3/src/main/resources/org/geotools/gml3/v3_2/gts</schemaLookupDirectory> >>>>> </schemaLookupDirectories> >>>>> >>>>> <!--destinationPackage>org.geotools.wfs.v2_0</destinationPackage--> >>>>> </configuration> >>>>> </plugin> >>>>> >>>>> The folder for wfs.v1.0 does not appear in the above configuration? It >>>>> contains: >>>>> >>>>> OGC-exception.xsd >>>>> WFS-basic.xsd >>>>> WFS-capabilities.xsd >>>>> WFS-transaction.xsd >>>>> >>>>> Ian did you run any of this stuff, or was the >>>>> WFSConfiguration_1_0.java renamed accidentally? >>>>> >>>>> -- >>>>> Jody Garnett >>>>> >>>>> >>>>> On Fri, 26 Oct 2018 at 17:43, Torben Barsballe < >>>>> tbarsba...@boundlessgeo.com> wrote: >>>>> >>>>>> During the EMF upgrade, it appears that >>>>>> org.geotools.wfs.v1_0.WFSConfiguration.java >>>>>> moved to >>>>>> <https://github.com/geotools/geotools/commit/e01e2e742e8bbe217bb316cd1698f40caac11de7#diff-a7f999b5c6810d418516e0c496627333R27> >>>>>> org.geotools.wfs.v1_0.WFSConfiguration_1_0.java >>>>>> >>>>>> The other (v1_1, v2_0) WFSConfiguration classes were* not *renamed. >>>>>> This seems inconsistent - are we concerned? >>>>>> >>>>>> This also caused an upstream compile failure in GeoServer, which I >>>>>> have fixed >>>>>> <https://github.com/geoserver/geoserver/commit/0e7bcbc5e34147c90b17267f9666d291db7bf766> >>>>>> . >>>>>> >>>>>> Torben >>>>>> _______________________________________________ >>>>>> GeoTools-Devel mailing list >>>>>> GeoTools-Devel@lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>>>>> >>>>> >>>> >>>> -- >>>> Ian Turton >>>> >>> -- >>> -- >>> Jody Garnett >>> >> >> >> -- >> Ian Turton >> > -- > -- > Jody Garnett > -- Ian Turton
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
