I was able to build this version: http://svn.geotools.org/branches/2.5.x
so i guess there seems to be a problem in web src.zip distribution.
This is the extended error i get when compiling web src 2.5.5
>
> [INFO] Fatal error compiling
>
> Embedded error: Error while executing the external
Improve support for encoding complex features
-
Key: GEOT-2474
URL: http://jira.codehaus.org/browse/GEOT-2474
Project: GeoTools
Issue Type: Improvement
Components: ext xml-xsd
Affects
Hi all.
As suggested by Simone, I'm splitting the discussion in two parts,
and this one is about the PMC refresh.
So far we nominated a set of possible candidates (sorted
by first name, this is not expressing a preference of mine):
- Ben Caradoc Davies
- Christian Müller
- Gabriel Roldan
- Michael
Yes, I am interested
Andrea Aime writes:
> Hi all.
> As suggested by Simone, I'm splitting the discussion in two parts,
> and this one is about the PMC refresh.
>
> So far we nominated a set of possible candidates (sorted
> by first name, this is not expressing a preference of mine):
> - Ben
update:
I downloaded the newest maven and then i was able to build geotools 2.5.5
webpage src (modules only, due to main pom circular dependency)
Blaz wrote:
>
> I was able to build this version: http://svn.geotools.org/branches/2.5.x
>
> so i guess there seems to be a problem in web src.zip
I'm flattered to see my name there - many thanks :)
However, I feel that my knowledge of GeoTools is quite narrow compared
to many other active contributors. There are certainly many parts of
the library that I haven't used or studied and know little about. My
understanding is that PMC members s
I'd add Daniele Romagnoli if he is interested of course.
Simone.
---
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob:+39 33
Hi,
I am interested. Yet, I think we need further discuss whether my
inclusion, if made, would lead to an over representation of OpenGeo and
whether that'd be a bad thing.
That is to say I am personally interested but wouldn't have any problem
in stepping back as a candidate.
Cheers,
Gabriel
+1.
Andrea Aime wrote:
> Hi,
> trying to recap that long thread so that we can see some
> action:
> - OSGEO repo is going to host only final releases
> - OpenGeo repo is going to host the snapshots (and be
>fed by Hudson daily?)
> - we'll remove all gt2 SNAPSHOT jars from OSGEO
>
> Is this ok
I for one would be willing to step back in order to let someone else at
opengeo have a go at being on the PSC. I have always felt that the voice
I had as only a module maintainer was adequate to be heard. And I think
some frequent turnover might just be what we need to revitalize the PSC.
Gabri
Ben Caradoc-Davies wrote:
> Jody Garnett wrote:
>>> Jody,
>>>
>>> is it expected that ComplexType.getDescriptor will return a descriptor from
>>> a Complex super type? ComplexTypeImpl does not do this. For example, if you
>>> create a FeatureType that has a supertype of
>>> GMLSchema.ABSTRACTFEATUR
This is indeed a trade off we ran up against when doing the initial
implementation of the model. The plan was basically to leave the object
structure mirroring the xml schema structure (and I am just assuming xml
schema for simplicity sake).
Then basically have the implementation responsible fo
Jaeger, Pascal wrote:
> Thanks for the information Justin.
> But I'm a little bit lost right now.
> These classes have been in the core quite a long time and are now unstable?
>
Yes they were... but they were put there prematurely. The instability
comes from simply lack of testing really, a bit
Justin Deoliveira wrote:
> This is indeed a trade off we ran up against when doing the initial
> implementation of the model. The plan was basically to leave the object
> structure mirroring the xml schema structure (and I am just assuming xml
> schema for simplicity sake).
>
> Then basically h
See http://hudson.opengeo.org/hudson/job/geotools-2.5.x/419/changes
Changes:
[simonegiannecchini] -removed command line utilities (I'll add them back as
separate utilities)
-remove dependency from common cli
-more clean up in index builder code
[simonegiannecchini] -GEOS-2985
-simplified index
See http://hudson.opengeo.org/hudson/job/geotools-2.5.x/420/changes
--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
K
As a community member (and not putting myself forward here!) I'm very
happy to see the level of available expertise and interest, and would
like to thank you all for efforts and being willing to step up.
I do have a question regarding the Geotoolkit issue - or rather the
strategy for managing the
Thanks for opening up a new discussion thread; I would like to go
through the normal nomination process here. Here is the part of the
developer guide from that;
http://docs.codehaus.org/display/GEOT/4+Project+Management+Committee I
would like a single email thread per nomination; the nomination can
+1
On Wed, May 6, 2009 at 4:29 PM, Andrea Aime wrote:
> Hi,
> trying to recap that long thread so that we can see some
> action:
> - OSGEO repo is going to host only final releases
> - OpenGeo repo is going to host the snapshots (and be
> fed by Hudson daily?)
> - we'll remove all gt2 SNAPSHOT
Justin,
I have one module with two unit tests that each pass if run by
themselves Each test uses a separate instance of the GeoServer
OneTimeTestSetup infrastructure, and each sets up a different mock
GeoServer data directory, which contains an OASIS catalog. Each data
directory is removed whe
Justin,
is the GML 3.2 support in xsd-gml3 ready? As I understand it, because
GML 3.2 has a separate namespace, we should be able to use it alongside 3.1.
If you are happy with your implementation, I will try to use it.
Kind regards,
--
Ben Caradoc-Davies
Software Engineer, CSIRO Exploration
Does anyone have source jars for the Eclipse emf common and ecore, and
Eclipse xsd? There are no sources in the repos, and it the Eclipse
download site has only large SDK bundles. The absence of source makes
debugging a royal PITA.
Here are the binary jars for which I have no source:
eclipse/e
Justin Deoliveira wrote:
[ComplexType with ComplexType as superType]
> Then basically have the implementation responsible for searching the
> parent types when asked for a descriptor. I seem to remember a
> convenience method on the "Types" class that did this.
I could not find it. Types now per
Hi Ben,
Definitely seems like there is some caching going on. I have also seen
this error in cases where there is no appropriate resolver around to
handle a schema reference. I find it usually helps to know what schema
import or include it is choking on. Here is what I do:
1) link the emf sour
A while back I implemented support for the GML 3.2 schema to help out
Rob. Other than some trivial examples I never really did any real
testing. That said, all the setup is there, so ready for use.
And yeah, the different namespace uri *should* prevent any conflicts.
-Justin
Ben Caradoc-Davies
In case you missed it in my previous email:
http://repo.opengeo.org/org/eclipse/xsd/xsd/2.2.2/xsd-2.2.2-sources.jar
http://repo.opengeo.org/org/eclipse/emf/common/2.2.1/common-2.2.1-sources.jar
http://repo.opengeo.org/org/eclipse/emf/ecore/2.2.2/ecore-2.2.2-sources.jar
-Justin
Ben Caradoc-Davies
Tough to say how things will play out. I for one think the relationship
will depend on how the community around geotoolkit grows. It could be
that a somewhat different community than the current one will form, or
it could be that the current geotools community overwhelmingly flocks to
geotoolki
Thanks, I got it ... just took me a while to figure out why
maven-eclipse-plugin was ignoring the sources (see my last mail).
Justin Deoliveira wrote:
> In case you missed it in my previous email:
>
> http://repo.opengeo.org/org/eclipse/xsd/xsd/2.2.2/xsd-2.2.2-sources.jar
> http://repo.opengeo.o
Thanks, Justin, I'll see if it works. GeoSciML 2.0 sneaked in a GML 3.2
dependency, which makes GeoServer very unhappy, so GML 3.2 support would
be very handy.
Kind regards,
Ben.
Justin Deoliveira wrote:
> A while back I implemented support for the GML 3.2 schema to help out
> Rob. Other than
Justin Deoliveira wrote:
> 1) link the emf sources to your eclipse workspace, i just made sure the
> source jars are in our maven repo:
> http://repo.opengeo.org/org/eclipse
Thanks very much for that, Justin.
Note that, to get source attachment working with
maven-eclipse-plugin:2.4, I had to man
30 matches
Mail list logo
