See http://hudson.opengeo.org/hudson/job/geotools-2.5.x/260/changes
Changes:
[groldan] added missing dummy api stuff
[groldan] a number of test improvements
--
[...truncated 6423 lines...]
[INFO] [jar-collector:collect {execution: default}]
[INFO] [instal
Never mind; I was just undone by trying to run rename.xml script now that it
is no longer in the home directory.Jody
On Mon, Feb 2, 2009 at 8:59 PM, Jody Garnett wrote:
> Tagged; but not bagged .. the release process does not quite work :-( This
> is somehow usual when making a tag; the artifact
Morning
On Tue, Feb 3, 2009 at 2:20 AM, Gabriel Roldan wrote:
> Hi guys,
>
> As you know I'm working on improving ArcSDE gce support by adding support
> for extra formats.
>
> So, the way it works is that we have a so called ArcSDERasterReader
> (extending ImageReader) for each pixel format. Ea
See http://hudson.opengeo.org/hudson/job/geotools-2.5.x/261/changes
--
[...truncated 6397 lines...]
[INFO] [jar-collector:collect {execution: default}]
[INFO] [install:install]
[INFO] Installing
http://hudson.opengeo.org/hudson/job/geotools-2.5.x/ws/gt_2.5.
Hi guys,
As you know I'm working on improving ArcSDE gce support by adding support for
extra formats.
So, the way it works is that we have a so called ArcSDERasterReader (extending
ImageReader) for each pixel format. Each one reads tile data in the
appropriate pixel packaging (float, byte, ush
Tagged; but not bagged .. the release process does not quite work :-(
This is somehow usual when making a tag; the artifacts in "build" keep
you from starting or something.
However I cannot remember how to get out of this catch 22
> Reason: Unable to download the artifact from any repository
>
>
Looks like I am going to try an hour later next week in order to say hi
to Andrea.
Frank stopped in and we had a look a MemoryDataStore; and added a
constructor to allow him to start off with an empty collection. Frank is
hopefully going to test that a while and let me know.
Andrea also stopped
The tag would be ideal, so the version numbers on the docs would match.
but a snapshot of 2.5.x should suffice too.
Jody Garnett wrote:
> I will start the process here; I have had some success in the past. I
> will update 2.5.x and build; will that be sufficient or do you really
> want the tag?
Hey Jody,
1) This should be on geotools, no?
2) gt2 doesn't build with java 6, only java 5
3) gt2 javadocs *do* require java6
--adrian, going out to brave the storm on the way home.
On Tue, 2009-02-03 at 09:47 +1100, Jody Garnett wrote:
> Okay so "legacy" will not compile unless you build the t
You are right; geotools-devel list only.- I can now build on Java 6 by
ignoring tests
- The instructions in the wiki produce javadocs on a module by module basis
- The earlier aggregate javadoc functionality does not seem to function on
this tag
Documentation:
-
http://docs.codehaus.org/display/GE
OnlineTestCase support for failure on failed connection
---
Key: GEOT-2320
URL: http://jira.codehaus.org/browse/GEOT-2320
Project: GeoTools
Issue Type: Improvement
Affects Versions: 2.6
I propose that an optional key be added to OnlineTestCase to cause test
failure on failed connection:
http://docs.codehaus.org/display/GEOTOOLS/OnlineTestCase+support+for+failure+on+failed+connection
--
Ben Caradoc-Davies
Software Engineer, CSIRO Exploration and Mining
Australian Resources Rese
Having just encountered yet another developer trying to do the right
thing by following the docs, and inflicting Jalopy brain damage on their
workspace, does anyone object if I expunge any Jalopy reference from the
wiki?
Jalopy brokenness has often been discussed, e.g:
http://n2.nabble.com/Jal
The code format mvn plugin still works last time I checked; is it not
making use of these Jalopy settings? For my own projects I now use
FindBugz (a similar static analysis tool).
For formatting I use eclipse.
But yeah this is a case of move it or lose it; can you check if the
source formattin
How would that be helpful? I could see throwing a java property to ask
the online tests to fail
Personally I log the first failed connection message.
Ben Caradoc-Davies wrote:
> I propose that an optional key be added to OnlineTestCase to cause test
> failure on failed connection:
> http://d
As my coworker just discovered, Jalopy modifies all code, even code that
has not been changed. This is a Bad Thing.
We both use Eclipse with the GeoTools formatter build/eclipse/formatter.xml
Mixing and matching with Jalopy will only cause pain. I don't even want
to try it. We know it is too ag
You might have some online resources under your control, and may wish
for these tests to fail when they cannot connect, while ignoring
connection failures in others. As noted by Andrea in our discussion last
August, this decision must be left to those configuring the online test
fixtures for a
17 matches
Mail list logo
