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
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
