Include app-schema in build

[Ben Caradoc-Davies]

I'm assuming that, because app-schema is an approved unsupported module,
I can include it in the build (once it passes on Hudson). I expect it to
add about two minutes to the build time. We are working to reduce this.

Any objections?

--
Ben Caradoc-Davies <[hidden email]>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Jody Garnett-2]

Not from here; you do have the option of marking tests that are
extensive and only engaging them if needed (we use that for some of
the really slow tests). Care should be taken to check tests are
isolated into OnlineTests if they hit other web services etc...

Jody

On Thu, Jul 9, 2009 at 1:04 PM, Ben
Caradoc-Davies<[hidden email]> wrote:

> I'm assuming that, because app-schema is an approved unsupported module,
> I can include it in the build (once it passes on Hudson). I expect it to
> add about two minutes to the build time. We are working to reduce this.
>
> Any objections?
>
> --
> Ben Caradoc-Davies <[hidden email]>
> Software Engineer, CSIRO Exploration and Mining
> Australian Resources Research Centre
> 26 Dick Perry Ave, Kensington WA 6151, Australia
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Ben Caradoc-Davies]

Jody Garnett wrote:
> Not from here; you do have the option of marking tests that are
> extensive and only engaging them if needed (we use that for some of
> the really slow tests).

Al the tests together take about two minutes. We intend to reduce this
substantially with some refactoring in the next few weeks. If this
causes problems until then, we may mark them as extensive, but I am
reluctant to disable any tests that we can keep.

> Care should be taken to check tests are
> isolated into OnlineTests if they hit other web services etc...

I believe this to already be the case. I might unplug my network and run
the unit tests to be sure.  :-)

--
Ben Caradoc-Davies <[hidden email]>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Justin Deoliveira]

So I assume this means adding app-schema to the profile which gets
engaged with -Dall ?

Ben Caradoc-Davies wrote:
> I'm assuming that, because app-schema is an approved unsupported module,
> I can include it in the build (once it passes on Hudson). I expect it to
> add about two minutes to the build time. We are working to reduce this.
>
> Any objections?
>


--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Ben Caradoc-Davies]

Yes, in modules/unsupported/pom.xml I moved it from its own "app-schema"
profile to the "unsupported" profile activated by -Dall. I performed
this change in r33530, and reverted it in r22531 when the build failed
(presumably because it uses -Dtest.maxHeapSize=256M).

As soon as -Dtest.maxHeapSize=256M is removed, I plan to re-enable it.

Justin Deoliveira wrote:

> So I assume this means adding app-schema to the profile which gets
> engaged with -Dall ?
>
> Ben Caradoc-Davies wrote:
>> I'm assuming that, because app-schema is an approved unsupported module,
>> I can include it in the build (once it passes on Hudson). I expect it to
>> add about two minutes to the build time. We are working to reduce this.
>>
>> Any objections?
>>
>
>

--
Ben Caradoc-Davies <[hidden email]>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[aaime]

Ben Caradoc-Davies ha scritto:
> Jody Garnett wrote:
>> Not from here; you do have the option of marking tests that are
>> extensive and only engaging them if needed (we use that for some of
>> the really slow tests).
>
> Al the tests together take about two minutes. We intend to reduce this
> substantially with some refactoring in the next few weeks. If this
> causes problems until then, we may mark them as extensive, but I am
> reluctant to disable any tests that we can keep.

I'm ok to put up with extensive build time and high memory usage for
a short time, provided there are serious plans to address both,
one way or the other. GeoTools has already bad rep enough without
having to require a server like setup to build it (512M heap
mean 600-700MB of real memory consumption factoring in the extra
stuff the VM is loading)

Another option could be to have the build server build with
-Pextensive (shall we rename this to -Pexpensive ;-) ?)
and leave the random developer without the extra burden.

Cheers
Andrea


--
Andrea Aime
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Ben Caradoc-Davies]

Andrea Aime wrote:
> I'm ok to put up with extensive build time and high memory usage for
> a short time, provided there are serious plans to address both,
> one way or the other. GeoTools has already bad rep enough without
> having to require a server like setup to build it (512M heap
> mean 600-700MB of real memory consumption factoring in the extra
> stuff the VM is loading)

Agreed.

> Another option could be to have the build server build with
> -Pextensive (shall we rename this to -Pexpensive ;-) ?)

+1 for the rename.

> and leave the random developer without the extra burden.

Jody has suggested using -Pextensive. We could also make our own
"app-schema-bloat-bloat-bloat" profile that we enable on our CI box.
Either of these would, in effect, disable some tests, and would infringe
on my TDD religious obligations.  ;-)

We (Rini and I) need to fix the bloat.

--
Ben Caradoc-Davies <[hidden email]>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[aaime]

Ben Caradoc-Davies ha scritto:

> Andrea Aime wrote:
>> I'm ok to put up with extensive build time and high memory usage for
>> a short time, provided there are serious plans to address both,
>> one way or the other. GeoTools has already bad rep enough without
>> having to require a server like setup to build it (512M heap
>> mean 600-700MB of real memory consumption factoring in the extra
>> stuff the VM is loading)
>
> Agreed.
>
>> Another option could be to have the build server build with
>> -Pextensive (shall we rename this to -Pexpensive ;-) ?)
>
> +1 for the rename.

I was just joking :)

>> and leave the random developer without the extra burden.
>
> Jody has suggested using -Pextensive. We could also make our own
> "app-schema-bloat-bloat-bloat" profile that we enable on our CI box.
> Either of these would, in effect, disable some tests, and would infringe
> on my TDD religious obligations.  ;-)
>
> We (Rini and I) need to fix the bloat.

This Eclipse XSD issue seem relevant as well and it's being discussed
these days too:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=278853

Also, an old thread on the eclipse ml suggests to use xerces-j schema
api instead of XSD if one does not have schema manipulation needs:
http://dev.eclipse.org/newslists/news.eclipse.technology.xsd/msg01221.html
This does not mean we have to jump on xerces-j api right away, just
that we keep it in mind for the future (this is the same API DeeGree is
using for its schema handling needs, too).

Cheers
Andrea


--
Andrea Aime
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Ben Caradoc-Davies]

Andrea Aime wrote:
>>> Another option could be to have the build server build with
>>> -Pextensive (shall we rename this to -Pexpensive ;-) ?)
>> +1 for the rename.
>
> I was just joking :)

I know, but it was a good suggestion.

> This Eclipse XSD issue seem relevant as well and it's being discussed
> these days too:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=278853

Could be relevant.

> Also, an old thread on the eclipse ml suggests to use xerces-j schema
> api instead of XSD if one does not have schema manipulation needs:
> http://dev.eclipse.org/newslists/news.eclipse.technology.xsd/msg01221.html
> This does not mean we have to jump on xerces-j api right away, just
> that we keep it in mind for the future (this is the same API DeeGree is
> using for its schema handling needs, too).

Mmm, we only consume schemas, so xerces-j may be an option. We do need
to walk the schemas to find things like substitution groups, and I am
not sure the xerces API allows this. Justin?

--
Ben Caradoc-Davies <[hidden email]>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Ben Caradoc-Davies]

Ben Caradoc-Davies wrote:
>> Care should be taken to check tests are
>> isolated into OnlineTests if they hit other web services etc...
>
> I believe this to already be the case. I might unplug my network and run
> the unit tests to be sure.  :-)

If I physically disconnect my network cable, I can:

(1) cd modules/unsupported/app-schema/app-schema

(2) mvn -o clean install

All tests pass, and the build succeeds (1 minute and 40 seconds).

--
Ben Caradoc-Davies <[hidden email]>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[aaime]

Ben Caradoc-Davies ha scritto:

> Ben Caradoc-Davies wrote:
>>> Care should be taken to check tests are
>>> isolated into OnlineTests if they hit other web services etc...
>> I believe this to already be the case. I might unplug my network and run
>> the unit tests to be sure.  :-)
>
> If I physically disconnect my network cable, I can:
>
> (1) cd modules/unsupported/app-schema/app-schema
>
> (2) mvn -o clean install
>
> All tests pass, and the build succeeds (1 minute and 40 seconds).

Just run the same here out of curiosity.

The build is very verbose, "resolveURI(...)" all over the place.
Can it be quieted down a little?
(almost all modules are guilty of being very chatty during the build
  due to extra debug statements forgot in the tests, but this one is
  really super super chatty, "mvn -o clean install | wc -l --> 7805 lines
  ;-) ).

It builds fine for me as well, same build time (which is good, some days
ago a few tests were failing on my machine).

Cheers
Andrea



--
Andrea Aime
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Ben Caradoc-Davies]

Andrea Aime wrote:
> Just run the same here out of curiosity.
> The build is very verbose, "resolveURI(...)" all over the place.
> Can it be quieted down a little?
> (almost all modules are guilty of being very chatty during the build
>   due to extra debug statements forgot in the tests, but this one is
>   really super super chatty, "mvn -o clean install | wc -l --> 7805 lines
>   ;-) ).

Ah, yes, the SchemaResolver crapflood. I suspected you might object to
it. I want to silence it as well. Every line is an imported schema, and
you can see the bloat. We have gotten used to it, and we find it
comforting to see the lines scroll by; kind of like a progress bar while
an app-schema DataAccess struggles to load.

I centralised all the Catalog construction code. Line 109 on
CatalogUtilities contains the offending setting:
catalogManager.setVerbosity(9);

I will try changing this to a less verbose value.

> It builds fine for me as well, same build time (which is good, some days
> ago a few tests were failing on my machine).

Great!

--
Ben Caradoc-Davies <[hidden email]>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Ben Caradoc-Davies]

Ben Caradoc-Davies wrote:
> Andrea Aime wrote:
>> Just run the same here out of curiosity.
>> The build is very verbose, "resolveURI(...)" all over the place.
>> Can it be quieted down a little?
> I centralised all the Catalog construction code. Line 109 on
> CatalogUtilities contains the offending setting:
> catalogManager.setVerbosity(9);
> I will try changing this to a less verbose value.

I tried all possible values. Looks like it is either all or nothing. I
just changed it to nothing. It still emits warnings, and I am not sure
if it is using a logger. This is, I think, an apache-commons resolver
problem.

--
Ben Caradoc-Davies <[hidden email]>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Gabriel Roldan]

Ben Caradoc-Davies wrote:

> Andrea Aime wrote:
>>>> Another option could be to have the build server build with
>>>> -Pextensive (shall we rename this to -Pexpensive ;-) ?)
>>> +1 for the rename.
>> I was just joking :)
>
> I know, but it was a good suggestion.
>
>> This Eclipse XSD issue seem relevant as well and it's being discussed
>> these days too:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=278853
>
> Could be relevant.
>
>> Also, an old thread on the eclipse ml suggests to use xerces-j schema
>> api instead of XSD if one does not have schema manipulation needs:
>> http://dev.eclipse.org/newslists/news.eclipse.technology.xsd/msg01221.html
>> This does not mean we have to jump on xerces-j api right away, just
>> that we keep it in mind for the future (this is the same API DeeGree is
>> using for its schema handling needs, too).
>
> Mmm, we only consume schemas, so xerces-j may be an option. We do need
> to walk the schemas to find things like substitution groups, and I am
> not sure the xerces API allows this. Justin?

Aren't the EMF XSD schemas being kept as metadata somehow for the
FeatureTypes/AttributeDescriptors so they're given to the encoder
instead of the encoder having to recreate them from the geotools
FeatureType? (which might introduce substantial differences between the
original schema and the reverse engineered ones?)

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Gabriel Roldan]

Ben Caradoc-Davies wrote:

> Ben Caradoc-Davies wrote:
>> Andrea Aime wrote:
>>> Just run the same here out of curiosity.
>>> The build is very verbose, "resolveURI(...)" all over the place.
>>> Can it be quieted down a little?
>> I centralised all the Catalog construction code. Line 109 on
>> CatalogUtilities contains the offending setting:
>> catalogManager.setVerbosity(9);
>> I will try changing this to a less verbose value.
>
> I tried all possible values. Looks like it is either all or nothing. I
> just changed it to nothing. It still emits warnings, and I am not sure
> if it is using a logger. This is, I think, an apache-commons resolver
> problem.
>

I seem to recall those nasty logs come from the oasis catalog library
and never found a way to silent them (neither tried too hard though).

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Justin Deoliveira]

Ben Caradoc-Davies wrote:

> Andrea Aime wrote:
>>>> Another option could be to have the build server build with
>>>> -Pextensive (shall we rename this to -Pexpensive ;-) ?)
>>> +1 for the rename.
>>
>> I was just joking :)
>
> I know, but it was a good suggestion.
>
>> This Eclipse XSD issue seem relevant as well and it's being discussed
>> these days too:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=278853
>
> Could be relevant.
>
>> Also, an old thread on the eclipse ml suggests to use xerces-j schema
>> api instead of XSD if one does not have schema manipulation needs:
>> http://dev.eclipse.org/newslists/news.eclipse.technology.xsd/msg01221.html 
>>
>> This does not mean we have to jump on xerces-j api right away, just
>> that we keep it in mind for the future (this is the same API DeeGree is
>> using for its schema handling needs, too).
>
> Mmm, we only consume schemas, so xerces-j may be an option. We do need
> to walk the schemas to find things like substitution groups, and I am
> not sure the xerces API allows this. Justin?

Correct, we do inspect the schema contents quite closely, so any tech
needs to model every part of the schema down to small detail, this
includes particle information, and substitution group info.

We also do need the ability to build up schemas from scratch, this is
how the application schema stuff works, at least in geoserver. But I
agree, xerces-j is definition worth a look at.
>


--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Gabriel Roldan]

Justin Deoliveira wrote:

> Ben Caradoc-Davies wrote:
>> Andrea Aime wrote:
>>>>> Another option could be to have the build server build with
>>>>> -Pextensive (shall we rename this to -Pexpensive ;-) ?)
>>>> +1 for the rename.
>>> I was just joking :)
>> I know, but it was a good suggestion.
>>
>>> This Eclipse XSD issue seem relevant as well and it's being discussed
>>> these days too:
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=278853
>> Could be relevant.
>>
>>> Also, an old thread on the eclipse ml suggests to use xerces-j schema
>>> api instead of XSD if one does not have schema manipulation needs:
>>> http://dev.eclipse.org/newslists/news.eclipse.technology.xsd/msg01221.html 
>>>
>>> This does not mean we have to jump on xerces-j api right away, just
>>> that we keep it in mind for the future (this is the same API DeeGree is
>>> using for its schema handling needs, too).
>> Mmm, we only consume schemas, so xerces-j may be an option. We do need
>> to walk the schemas to find things like substitution groups, and I am
>> not sure the xerces API allows this. Justin?
>
> Correct, we do inspect the schema contents quite closely, so any tech
> needs to model every part of the schema down to small detail, this
> includes particle information, and substitution group info.
>
> We also do need the ability to build up schemas from scratch, this is
> how the application schema stuff works, at least in geoserver. But I
> agree, xerces-j is definition worth a look at.
>

I would hold horses before even thinking on switching xsd libraries,
that'd be just too much work. If we let the profiler speak though, it
doesn't seem like the biggest offender is EMF XSD itself, but our (my)
own code. For example, if I run _only_ the FeatureChainingTest mappings
load method through the profiler (that is, parsing the mappins, the xsd
schemas to EMF XSD and the EMF XSD model to
FeatureType/AttributeDescriptor), it needs 74M Heap space. But if I omit
  the last step (that is, parsing the mappins and the xsd schemas to EMF
XSD, omiting the transformation from EMF model to
FeatureTypes/AttribtueDescriptors), it only needs 22M Heap.
That is, the geotools model takes ~2.5 as much space as the EMF one,
hence my suggestion of transforming only the _needed_ EMF objects to
GeoTools ones instead of the whole schemas.


aside, see my previous post "app-schema build time/mem" for some more
insight on optimizing build resources.


--
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[aaime]

Gabriel Roldan ha scritto:

> I would hold horses before even thinking on switching xsd libraries,
> that'd be just too much work. If we let the profiler speak though, it
> doesn't seem like the biggest offender is EMF XSD itself, but our (my)
> own code. For example, if I run _only_ the FeatureChainingTest mappings
> load method through the profiler (that is, parsing the mappins, the xsd
> schemas to EMF XSD and the EMF XSD model to
> FeatureType/AttributeDescriptor), it needs 74M Heap space. But if I omit
>   the last step (that is, parsing the mappins and the xsd schemas to EMF
> XSD, omiting the transformation from EMF model to
> FeatureTypes/AttribtueDescriptors), it only needs 22M Heap.

Yep, our objects are very heavy and likely for a simple reason: heavy
use of hashmaps. Hashes are quite likely the most memory intensive
collection in Java, indiscriminate use of it leads to higher
memory consumption.

Cheers
Andrea

--
Andrea Aime
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel