You got it. Remember I commented out AppSchemaDataAccessIntegrationTest which I don't know why it doesn't get the gsml types (though gsml not being imported might be the reason).
Cheers, Gabriel rini.angre...@csiro.au wrote: > OK sure. > > Cheers > Rini > > -----Original Message----- > From: Gabriel Roldan [mailto:grol...@opengeo.org] > Sent: Friday, 10 July 2009 2:41 PM > To: Angreani, Rini (E&M, Kensington) > Cc: Caradoc-Davies, Ben (E&M, Kensington); > geotools-devel@lists.sourceforge.net > Subject: Re: [ExternalEmail] Re: [Geotools-devel] app-schema build time/mem > > Hi Rini, > > I can do that right away but there's a gotcha. I got a single test > failing that I'm finding myself unable to fix: > AppSchemaDataAccessIntegrationTest. > > Problem seems to be that it references mineralOccurrence.xsd but it > doesn't import Gsml.xsd and hence GeologicUnitType can't be found. I'm > not sure why it worked before though cause the logic didn't essentially > changed. May be if I commit you'll be able to assess it? (as it extends > DataAccessIntegrationTest but I'm not sure exactly what for, other than > to reuse the fake DataAccess on it?) > > What I did is the following: > I decoupled the xsd to EMF and EMF to GeoTools parsing so that they're > the responsibilities of different classes. > > So I like the separation of concerns more that way. EmfAppSchemaReader > now only cares about parsing the schemas into SchemaIndex. The new class > FeatureTypeRegistry takes them to parse the EMF objects on demand. This > means not all the types and elements are parsed to geotools objects but > only the needed ones, decreasing the memory usage lot. From 255m to 52m > for FeatureChainingTest, for example. > > I can build now with 256m in 59 seconds. I think with that and your > <schemaUri> magic we should be more than good. But certainly I didn't > have time to test that on the wild (ie, with geoserver). > > Are you still going to let me commit? > > Cheers, > > Gabriel > > rini.angre...@csiro.au wrote: >> It seems that way. >> Go ahead and commit your changes first. We have the whole day here still. >> >> Cheers >> Rini >> >> -----Original Message----- >> From: Gabriel Roldan [mailto:grol...@opengeo.org] >> Sent: Friday, 10 July 2009 2:16 PM >> To: Angreani, Rini (E&M, Kensington) >> Cc: Caradoc-Davies, Ben (E&M, Kensington); >> geotools-devel@lists.sourceforge.net >> Subject: Re: [ExternalEmail] Re: [Geotools-devel] app-schema build time/mem >> >> That's cool, so it seems that way it uses the Oasis catalog? >> >> btw, I'm about to get ready a patch to get the resource consumption even >> lower, but am afraid of getting too much conflicts with your changes. Do >> you think you can commit the test refactorings relatively soon? >> >> Cheers, >> Gabriel >> >> rini.angre...@csiro.au wrote: >>> I think I found the culprit. >>> I refactored a bunch of tests to run the set up once, it got faster, but >>> not enough. >>> Then I changed all the test mapping files to point to: >>> <schemaUri>http://schemas.opengis.net/GeoSciML/geosciml.xsd </schemaUri> >>> Instead of the local schemas in test-resources. >>> >>> Now I can run all gt-app-schema tests with 256 M :D. >>> I will make sure I didn't break any geoserver app-schema tests before I >>> commit. >>> >>> -----Original Message----- >>> From: Gabriel Roldan [mailto:grol...@opengeo.org] >>> Sent: Friday, 10 July 2009 11:54 AM >>> To: Caradoc-Davies, Ben (E&M, Kensington) >>> Cc: Angreani, Rini (E&M, Kensington); Geotools-Devel list >>> Subject: Re: [ExternalEmail] Re: [Geotools-devel] app-schema build time/mem >>> >>> Ben Caradoc-Davies wrote: >>>> Ben Caradoc-Davies wrote: >>>>> Thanks Gabriel, that is a definite improvement. GEOT-2608 committed as >>>>> r33538. >>>> Still not enough to get FeatureChainingTest to run with 256M heap, as on >>>> Hudson. >>>> >>> nope, but because of a memory leak. If you run FeatureChainingTest only >>> you can do that with 128m: >>> mvn test -Dtest=org.geotools.data.complex.FeatureChainingTest >>> -Dtest.maxHeapSize=128m -o >>> >>> So the two improvements needed keep being: >>> - lazy parsing of emf elements/types into gt descriptors/types >>> - fix mem leak (DataAccessRegistry is my suspect) >>> >>> I am looking into the former now. No promises though, it's getting late, >>> but I may hopefully come up with at least a sensible plan. >>> >>> As for the seconds, I would also like to provide a patch. But may be >>> over the weekend as this is spare time. >>> >>> Cheers, >>> Gabriel >> > > -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
