Jody Garnett a écrit :
> Martin I have made another bug report describing the changed directory
> structure for main (ie split out data/jdbc/xml)
> and linked it as related to the bug above... if you give me a specific
> time on Sunday I can help out.
Thanks. I guess that I will start around 15h
Martin Desruisseaux wrote:
> Unless someone object, I will reorganize the directory structure on trunk
> (branches will be left untouched):
>
> http://jira.codehaus.org/browse/GEOT-982
>
Martin I have made another bug report describing the changed directory
structure for main (ie split out dat
Unless someone object, I will reorganize the directory structure on trunk
(branches will be left untouched):
http://jira.codehaus.org/browse/GEOT-982
I plan to perform the reorganization this Sunday. It will affect every modules.
If you have pending work to commit to trunk, I suggest to commit
Sigh - teach me to try and sneak email in between two many activities
:-( Sorry David / Adrian.
Jody
>
>
> Jody Garnett wrote:
>> Hi David, nice rant ... fixing this situation (even with a basic user
>> intro that covers the most commonly useful 30% of the library is that
>> I want to see
>> tac
Cory Horner wrote:
> Howdy,
>
> We're changing the way uDig uses transactions -- so a transaction is
> AUTO_COMMIT until a modification occurs, and it remains open until the
> user commits the transaction:
>
Note:
Some feature source / store methods make use of their own internal
transaction
I'm in favor.
Is this related to GEOT-894?
At 07:14 PM 10/17/2006, Cory Horner wrote:
>Howdy,
>
>We're changing the way uDig uses transactions -- so a transaction is
>AUTO_COMMIT until a modification occurs, and it remains open until the
>user commits the transaction:
>
>http://jira.codehaus.org/
Howdy,
We're changing the way uDig uses transactions -- so a transaction is
AUTO_COMMIT until a modification occurs, and it remains open until the
user commits the transaction:
http://jira.codehaus.org/browse/UDIG-1051
Here is a patch for module/main which shows the line which needs to be
rem
Jody Garnett wrote:
Hi David, nice rant ... fixing this situation (even with a basic user
intro that covers the most commonly useful 30% of the library is that I
want to see
tackled before we graduate the OSGeo incubation process.
For now:
- David Adler is working on something (he had a whol
Hi Again:
I have updated the use page to mention that presentation:
- http://docs.codehaus.org/display/GEOTOOLS/Use
The situation is not likely to improve right now, our existing sponsors
are much more concerned about
quality then a user community, if you can think of another angle to
pursue th
Hi David, nice rant ... fixing this situation (even with a basic user
intro that covers the most commonly useful 30% of the library is that I
want to see
tackled before we graduate the OSGeo incubation process.
For now:
- David Adler is working on something (he had a whole wack of questions
and
I will create a JIRA task with attached files (initial JUnit test and basic
method implementation) tomorrow.
My opinion that it would be nice to have a general interface method like:
DataStore.modifySchema(String typeName, AttributeType[] removedTypes,
AttributeType[] addedTypes, Expression[] a
Cory Horner a écrit :
> This sounds okay, as I believe the file was placed there arbitrarily.
I have no objection neither. If the move is applied on the 2.3 branch, it would
just be nice if it is applied on trunk to before Sunday. (If you can't, we can
report the reorganization scheduled for Sun
Adrian Custer wrote:
>src/ currently contains two files needed during assembly. The name of
>this directory doesn't represent at all its contents and adds a top leve
>directory that seems useless. I'd like to move
> src/main/assembly
>to
> maven/assembly
>which would require a change to two lin
Jan Jezek a écrit :
> I propose that Builder should throw some Exception in that case (it
> throws exception just when the matrix is 100% singular, but in our case it is
> just near singularity). I just have to find somewhere how to determine that.
If you can find someway that would be great.
A
Hi,
The cause of random test failure seems to be in the accuracy of calculation
when the generated points build the matrix that is near singularity. I
propose that Builder should throw some Exception in that case (it
throws exception just when the matrix is 100% singular, but in our case it
Adrian Custer a écrit :
> mvn javadoc:javadoc builds successfully on 2.3.x with a 1.4 java!
Well, the fact that it work with 1.4 is accidental - I didn't tested that.
> @code - 8451 (our taglet doesn't seem to run correctly)
Do we have such taglet? I didn't had any on my side.
> @see- 1
Adrian Custer a écrit :
> Am I to understand that this cleanup is about to happen this Sunday? If
> so, I missed the info in the IRC log. A global announcement would be
> appreciated.
Yes, it was a little bit late for me yesterday. But I will open a JIRA task
with
more details and post an email
Martin, you rock!
(well, you and the maven crew that updated their package)
mvn javadoc:javadoc builds successfully on 2.3.x with a 1.4 java!
We still get 11,000+ errors, broken down as follows:
@code - 8451 (our taglet doesn't seem to run correctly)
@see- 1174 (this may still be partl
Hey all,
Am I to understand that this cleanup is about to happen this Sunday? If
so, I missed the info in the IRC log. A global announcement would be
appreciated.
--adrian
On Mon, 2006-10-16 at 17:02 -0700, Jody Garnett wrote:
> Martin we will need to update the developers guide after your chang
On Tue, 2006-10-17 at 08:57 -0400, David Adler wrote:
> Thank you. I didn't realize it was as simple as just specifying the
> top-level jar and that Java would then find all the other required jars if
> they were in the same directory. I started out with Java 1.0/1.1 when it
> was pretty dumb
Thank you. I didn't realize it was as simple as just specifying the
top-level jar and that Java would then find all the other required jars if
they were in the same directory. I started out with Java 1.0/1.1 when it
was pretty dumb about finding required classes.
What do you mean by "demo-in
Hello,
On Tue, 2006-10-17 at 07:19 -0400, David Adler wrote:
> Is there any script or readme file to run this? Or documentation on what
> jar files are pre-requisites at runtime?
For a cheap version, the pre-requisites is opening the binary
distribution into a folder (i.e. dropping *all* of the
Hey all,
src/ currently contains two files needed during assembly. The name of
this directory doesn't represent at all its contents and adds a top leve
directory that seems useless. I'd like to move
src/main/assembly
to
maven/assembly
which would require a change to two lines in the pom.xml.
It isn't clear what the target user audience is for GeoTools.
For the 2.0/2.1 era of GeoTools, there is a considerable set of examples
and snippets and other documentation to help in building GeoTools
applications. We modified the Spearfish demo to work with DB2.
Many of these are no longer v
Is there any script or readme file to run this? Or documentation on what
jar files are pre-requisites at runtime?
It took over an hour to get this going, finding the jar files one by one
after getting "ClassNotFound" errors.
Is there some straightforward way of determining what the pre-requisi
25 matches
Mail list logo
