Jody Garnett a écrit :
> 1) Upgrate maven-surefire-plugin to 2.3 (we are still using 2.2).
[snip]
> However the upgrate to maven-surefire-plugin 2.3 may not be completly smooth.
> Last time we tried, we got test failures (probably related to classloaders)
> and
> had the downgrate to surefire 2.2.
I'm not aware of anyone raising this issue, and cannot comment on it
from personal knowledge.
I'll try to dig a little deeper and see what the provenance of the
19125 spec is, but I'd think that the starting point would be the OGC
contact (is this Chris?). OGC has a liaison with ISO TC211, but I'm
See http://gridlock.openplans.org:8080/hudson/job/geotools-trunk/188/changes
Changes:
[groldan] GEOT-1680, implement getBounds and getCount
--
[...truncated 3652 lines...]
[WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
[INF
Yep I am still holding things up; we need to send out an email to past
committers etc...
Mean while Grass and FDO look to be through the graduation process; in
particular the FDO providence review is a great example of what we need
for GeoTools at the end of the day:
- http://wiki.osgeo.org/ind
Martin Desruisseaux ha scritto:
> Jody Garnett a écrit :
>> What is the maven support for JUnit4 like?
>
> I'm using it since a few months for seagis project and it work very well.
>
> The only requirements are:
>
> 1) Upgrate maven-surefire-plugin to 2.3 (we are still using 2.2).
> 2) Upgrate j
Jody Garnett a écrit :
> What is the maven support for JUnit4 like?
I'm using it since a few months for seagis project and it work very well.
The only requirements are:
1) Upgrate maven-surefire-plugin to 2.3 (we are still using 2.2).
2) Upgrate junit to 4 (I use 4.3.1).
However the upgrate to
I am with Gabriel; JUnit4 and Easy mock is something I have used on
another project with out incident. What is the maven support for JUnit4
like?
Still the fact that a couple of us already have experience is a good
sign that we should consider upgrading.
Jody
> I looked around, JMock is there, b
Justin Deoliveira ha scritto:
> So what is the consensus on backwards compatibility? I have heard
> statements saying it is completely 100% backwards compatible, and others
> saying it requires a different package?
>
> Either way I am probably +1, just want to be clear.
Both statements are correc
So what is the consensus on backwards compatibility? I have heard
statements saying it is completely 100% backwards compatible, and others
saying it requires a different package?
Either way I am probably +1, just want to be clear.
Mauricio Pazos wrote:
> On Monday 28 January 2008, Simone Giannecc
On Monday 28 January 2008, Simone Giannecchini wrote:
> > I'm +1 for upgrating to JUnit 4 at least on trunk (I'm indifferent for
> > 2.4 branch).
> >
> > Martin
+1 for trunk too
regards
--
Mauricio Pazos
www.axios.es
tel-:+34 94 441 63 84
---
+1 as well.
Simone.
On Jan 28, 2008 5:46 PM, Martin Desruisseaux
<[EMAIL PROTECTED]> wrote:
> I'm +1 for upgrating to JUnit 4 at least on trunk (I'm indifferent for 2.4
> branch).
>
>Martin
>
>
> -
> This SF.net emai
I'm +1 for upgrating to JUnit 4 at least on trunk (I'm indifferent for 2.4
branch).
Martin
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MR
[
http://jira.codehaus.org/browse/GEOT-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabriel Roldán reopened GEOT-1696:
--
reopening to assign the issue to the correct module
> WFSParsingTest.parseDescribeFeatureType fails if th
Justin Deoliveira ha scritto:
> Thanks for fixing that issue Martin.
>
> FYI, I am currently running into this second issue with our wfs 1.1
> reference implementation.
Even after rebuilding gt2? Any test case I can have a look at?
Cheers
Andrea
--
WFSParsingTest.parseDescribeFeatureType fails if there's a GeoServer instance
running at localhost
--
Key: GEOT-1696
URL: http://jira.codehaus.org/browse/GEOT-1696
Xlink online resource fails to parse if the element uses both xlink:type and
xlink:href
---
Key: GEOT-1695
URL: http://jira.codehaus.org/browse/GEOT-1695
Project: Geo
No, i have yet to rebuild gt2 and re-upload the new RI. It is just I saw
that stack trace you supplied and it was the same one the wfs client
people are getting.
It was quite reproducible, a simple GetFeature with in a POST. I will
rebuild the RI and see if it persists.
Andrea Aime wrote:
> Justi
remove converter which goes from collection to array
Key: GEOT-1694
URL: http://jira.codehaus.org/browse/GEOT-1694
Project: GeoTools
Issue Type: Bug
Components: core xml
Affe
Thanks for fixing that issue Martin.
FYI, I am currently running into this second issue with our wfs 1.1
reference implementation.
-Justin
Martin Desruisseaux wrote:
> Andrea Aime a écrit :
>> Out of curiousity, what is the set of Hints one would have to set in
>> order to mimic the org.geotools
I have had good experience transitioning from junit3 to junit4. The two
can coexist as they use different package names
and have backward compatibility.
Andrea Aime wrote:
> Hi,
> today I tried to fix a bug (http://jira.codehaus.org/browse/GEOT-1693)
> that required fixing DefaultFeatureResults
For the record, just tried to build geotools with Junit 4.4 and it went just
well, meaning its seems to actually be backwards compatible.
So if its a matter of upgrading the junit dependency, as it means by no reason
needing to upgrade the tests, I'd like to do that.
2 cnts.
Gabriel
On Monday
That's indeed very cool Andrea.
I've to say, to support Andrea's proposal, that I've been using
junit4+EasyMock for some time now on another project and its going perfectly,
and indeed provides for a true way of isolating unit tests, and helps design
testable code, etc.
Yet, I don't quite under
Hi,
today I tried to fix a bug (http://jira.codehaus.org/browse/GEOT-1693)
that required fixing DefaultFeatureResults and co. The issue with this
bug is that one cannot unit test DefaultFeatureResults without
creating a ton or related classes... unless mock testing is used.
So I gave a spin at Eas
Andrea Aime a écrit :
> Out of curiousity, what is the set of Hints one would have to set in
> order to mimic the org.geotools.referencing.forceXY=true system
> variable?
It should be only:
> Hints.putSystemDefault(Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER, true);
with no more hints... There is a o
Martin Desruisseaux ha scritto:
> Hopefully fixed on trunk as of revision 28977.
>
> I would appreciate if you have a chance to try... To be correct I should write
> more test cases, but I still stretched by time for this week...
Hum, Hudson just finished building both gt2 and gs trunk and both b
Hopefully fixed on trunk as of revision 28977.
I would appreciate if you have a chance to try... To be correct I should write
more test cases, but I still stretched by time for this week...
Regards,
Martin
FeatureCollection.size() does not respect maxFeatures
--
Key: GEOT-1693
URL: http://jira.codehaus.org/browse/GEOT-1693
Project: GeoTools
Issue Type: Bug
Components: data
Affe
Andrea Aime a écrit :
>> It seems some recent changes have broken many of the GEoServer test
>> cases which assume that a transformation from epsg:4326 to
>> urn:x-ogc:..:epsg:4326 will result in an axis flip.
Its a bug of mine. I tried to fix GEOT-1659 and didn't realized this underisable
side ef
Justin Deoliveira ha scritto:
> It seems some recent changes have broken many of the GEoServer test
> cases which assume that a transformation from epsg:4326 to
> urn:x-ogc:..:epsg:4326 will result in an axis flip.
>
> I have yet to look into the cause. Andrea, Martin: any ideas?
I can confirm it
29 matches
Mail list logo
