Surely we copy all unsupported modules over, so that they can be
developed and tested against the 2.4 branch and made available as
optional downloads.
If the "official" release only includes supported, thats fine.
IMHO We ought to make sure though that builds of the unsupported modules
can b
http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/1405
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/1404
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/1402
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/1401
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/1400
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
I see; and since none of my implementations extend
AbstractAuthorityFactory factory they are not getting picked up ... by
the DefaultAuthorityFactory find operation. I will take your advice and
create an abstract class rather than an interface.
Cheers,
Jody
> Jody Garnett a écrit :
>> The "Defa
http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/1398
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
I notice that the root pom references a location in the svn repository.
Does this not work unless the license is local?
Cory Horner wrote:
> Jody Garnett wrote:
>> Darn; as a PMC member you can officially hit them up for another one.
>> But I think we get the license through codehaus? So perhaps
Justin Deoliveira wrote:
> I notice that the root pom references a location in the svn repository.
> Does this not work unless the license is local?
It works fine with the remote URL; our build box has been generating
nightly clover reports for the last couple months.
http://lists.refractions.n
Jody Garnett wrote:
> Darn; as a PMC member you can officially hit them up for another one.
> But I think we get the license through codehaus? So perhaps you should
> start over on their IRC...
> Jody
>> I just tried to run the clover plugin to check test coverage and got an
>> error specifying
>
> Are you meaning the unsupported modules aren't copied over to the
> stable branch? This is nonsense, and would create quite some troubles
> for Geoserver, since we are providing some of the unsupported modules
> as extra datastores (Oracle, MySql, anyone? Lately Oracle saw more
> fixes than W
Darn; as a PMC member you can officially hit them up for another one.
But I think we get the license through codehaus? So perhaps you should
start over on their IRC...
Jody
> I just tried to run the clover plugin to check test coverage and got an
> error specifying the license is out of date?
>
I just tried to run the clover plugin to check test coverage and got an
error specifying the license is out of date?
-Justin
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
-
This SF.net email is s
Bring ArcSDE module to supported status
---
Key: GEOT-1387
URL: http://jira.codehaus.org/browse/GEOT-1387
Project: GeoTools
Issue Type: Task
Components: data arcsde
Affects Versions: 2.4-RC0
Justin Deoliveira ha scritto:
> Hello all,
>
> So it has come to my attention that unsupported modules to not make the
> cut when creating a stable branch... fair enough. From what I can tell
> the following unsupported modules are ready for prime time:
>
> arcsde
> db2
> xml-*
> postgis-versio
That is exactly correct Justin.
Mostly this is a documentation/formal-process thing. I'll shepard gt2-arsde
into supported land, and then bring it back to 2.4.x post-branch after the docs
and any necessary votes are done.
--saul
From: [EMAIL PROTECTED] on b
Hello all,
So it has come to my attention that unsupported modules to not make the
cut when creating a stable branch... fair enough. From what I can tell
the following unsupported modules are ready for prime time:
arcsde
db2
xml-*
postgis-versioned
Apologies if i have missed any. Although I th
Looks like a java 5 dependency (URL#toURI()) has crept in.
-Justin
Continuum wrote:
> http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/1396
>
> -
> This SF.net e
Jody Garnett wrote:
> Here are a couple of thoughts for the revision of referencing to take on
> the 2.4.x branch:
> 2.4-M3 is -r 25701 - which would make Martin happy (you would need to
> grab that revision of the epsg modules I bet)
> 2.4-M4 is -r 26076 - should be slightly less work for you
B
Here are a couple of thoughts for the revision of referencing to take on
the 2.4.x branch:
2.4-M3 is -r 25701 - which would make Martin happy (you would need to
grab that revision of the epsg modules I bet)
2.4-M4 is -r 26076 - should be slightly less work for you
> Hi all,
>
> So it appears tha
http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/1396
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
Sorry... the first line should read:
"So it appears that we *are ready* to branch 2.4".
Justin Deoliveira wrote:
> Hi all,
>
> So it appears that we are not ready to branch 2.4. Can you confirm this
> Jody. After the branch is created the plan is to release another
> milestone as there are st
Hi all,
So it appears that we are not ready to branch 2.4. Can you confirm this
Jody. After the branch is created the plan is to release another
milestone as there are still critical bugs open preventing the release
of RC0.
One thing that needs to be done once the branch is created is a
rever
Gertjan van Oosten ha scritto:
> Hi Andrea,
> [Note: I can't seem to change the Fix Version from 1.5.x to 1.5.2;
>I have no Edit rights.]
Btw, I updated the fix version. I suggest you subscribe to that issue
as a watcher, so you'll be informed when it's fixed :)
Cheers
Andrea
--
Gertjan van Oosten ha scritto:
> Hi Andrea,
>
> As quoted from Andrea Aime <[EMAIL PROTECTED]>:
>>> Querying is no problem, as is updating existing features. It is new
>>> features where things fail on the GeoServer side.
>> Ah, sorry for misunderstanding you. Yes, things are fixed only on the
>
Hi Andrea,
As quoted from Andrea Aime <[EMAIL PROTECTED]>:
> > Querying is no problem, as is updating existing features. It is new
> > features where things fail on the GeoServer side.
>
> Ah, sorry for misunderstanding you. Yes, things are fixed only on the
> read side, write side is most prob
invalid shapefile DBF header Arc9.2
---
Key: GEOT-1386
URL: http://jira.codehaus.org/browse/GEOT-1386
Project: GeoTools
Issue Type: Bug
Components: data shapefile
Environment: Windows Server
Gertjan van Oosten ha scritto:
> Hi Andrea,
>
> As quoted from Andrea Aime <[EMAIL PROTECTED]>:
>> I think you should look in the GML encoder, the FeatureTransformer class
>> in particular.
>
> I will have a looksee.
>
and then use DateUtils to encode
the date with the appropriate type
Hi Andrea,
As quoted from Andrea Aime <[EMAIL PROTECTED]>:
> I think you should look in the GML encoder, the FeatureTransformer class
> in particular.
I will have a looksee.
> >> and then use DateUtils to encode
> >> the date with the appropriate type, and you should get exactly the
> >> same be
Gertjan van Oosten ha scritto:
> Hi Andrea,
>
>> Locate where the feature is produced,
>
> I tried to follow the code, but I got lost. Any pointers?
I think you should look in the GML encoder, the FeatureTransformer class
in particular.
>> and then use DateUtils to encode
>> the date with the
Hi Andrea,
As quoted from Andrea Aime <[EMAIL PROTECTED]>:
> Gertjan van Oosten ha scritto:
> > When I try to insert a feature of this type (from my Java code, using
> > FeatureType, FeatureStore, FeatureCollection etc.), the data that gets
> > sent to the WFS-T (Geoserver) contains this on the wi
Gertjan van Oosten ha scritto:
> Hi Geotools developers,
>
> I'm having some problems with a feature type that has a dateTime element
> in its schema like this:
>
> [...]
>nillable = "true" maxOccurs = "1" />
> [...]
>
> When I try to insert a feature of this type (from my Java code, usi
On a related note: would it be possible to get the source of a WFS
transaction failure? What I see in the logs from gt2 is this:
11-Jul-2007 12:24:38 org.geotools.xml.XMLSAXHandler endElement
WARNING: java.lang.IllegalArgumentException: unable to parse Wed Feb 22
20:15:00 CET 1995 as Date
Hi Geotools developers,
I'm having some problems with a feature type that has a dateTime element
in its schema like this:
[...]
[...]
When I try to insert a feature of this type (from my Java code, using
FeatureType, FeatureStore, FeatureCollection etc.), the data that gets
sent to the WF
35 matches
Mail list logo
