Hmmm... From my knowledge we have always depended on commons logging,
just not used it. I believe it is necessary since some of the other
commons-* libraries use it. Perhaps I am mistaken...In this case it is
commons-beanutils for doing the expression conversion stuff. Since this
this was introduce
Hi,
No idea what to do about this but I'm told there isn't supposed to be
dependencies on commons logging. However there is. Here's the stack
trace from StreamingRenderer:
at org.geotools.renderer.lite.StreamingRenderer.paint
(StreamingRenderer.java:738)
at org.geotools.renderer.lite.S
Martin Desruisseaux wrote:
> I tried to remove "jar-collector" and realized that our assembly plugin (as we
> use it) relies on it, so I keep it for now. It may be possible to avoid this
> dependency if we spent some time exploring the element in
> assembly descriptor (gt2/build/maven/assembly/bin
groldan++
You are correct the implementation of Length needs to be fixed exactly
as you outlined.
There are two more missing parts to Filter:
- we need to have a plugin system behind our spatial functions (so they
can use ISO Geometry as well as JTS)
- Function.getNumberOfArguments() is not pre
TypeName and Name equals() implementations are not symetric
---
Key: GEOT-1252
URL: http://jira.codehaus.org/browse/GEOT-1252
Project: GeoTools
Issue Type: Bug
Components: cor
Hi all,
if you remember, I've talked about using a custom FilterFactory and thus
Filter* implementation for dealing with ISO Feature.
It turned out to not be necessary, as the Filter implementation is "pluggable"
enough (i.e. using PropertyAccessors and Converters should just make the
trick).
Bah - I am really sad about this. A delay in getting permission to edit
a wiki page really means the difference between people contributing or not.
The new process for [edit this page] is the same one geoserver uses for
svn access: http://docs.codehaus.org/display/GEOSDOC/1+Getting+Commit+Status
Your solution is the correct one Gabriel - thanks for finding and fixing
the problem.
Cheers,
Jody
Gabriel Roldán wrote:
> Hi,
>
> TypeName and Name equals() implementations are not symetric, as TypeName
> extends Name, and Name's equals checks for instanceof Name, it returns true
> if the argu
I did not try that - it ended up working for me the moment I used Java
5. I think the way we are supposed to do things is to have a clover
license in one spot, right now Cory has a license in each module as I
understand it.
If your solution works then perhaps we can cut down on the duplication
You are of course correct Martin.
I figured that out myself yesterday; but I was so sick of sending email
to the list that I just made a note of the result in the anouncement
(rather then seperate email).
Jody
Martin Desruisseaux wrote:
> Jody Garnett a écrit :
>
>> Looking at the pom.xml it
Agreed - I think we are all upset on this one.
I have a slightly different take on matters - I saw email discussion
start up three or four times - the missing part for me was a decision.
I think all the developers know by now that changing anything in the
build system costs at least a day in
With an increase in the number of spam users (people signing up and
wrecking websites with google ranking induced links) codehaus has been
restricting permissions on our various wiki spaces.
So our "edit this page" link will be the same process as requesting
permission for svn, go through xircl
Hi,
TypeName and Name equals() implementations are not symetric, as TypeName
extends Name, and Name's equals checks for instanceof Name, it returns true
if the argument is a TypeName, but TypeName returns false if the argument is
a Name.
I thought the solution would be to not make TypeName ext
Jody Garnett a écrit :
> Looking at the pom.xml it looks like "mvn -Psite.build site" will only
> work for Java 1.4 - since that is our release environment we should be okay.
Well, one or two months ago "mvn site" was rather intended for execution with
Java 5, because of javadoc.
Just tried on m
Jody Garnett a écrit :
> It looks like Andrea and Cory both have a license in the required
> location(http://svn.geotools.org/geotools/trunk/gt/build/maven/build-configs/src/main/resources/gt2/)
>
> andrea do you know anything more about clover - or can I just disable
> this report for now?
I
I tried to remove "jar-collector" and realized that our assembly plugin (as we
use it) relies on it, so I keep it for now. It may be possible to avoid this
dependency if we spent some time exploring the element in
assembly descriptor (gt2/build/maven/assembly/binaryDist.xml) and see if it can
be a
On Wed, 2007-04-25 at 12:06 +0200, Martin Desruisseaux wrote:
> Justin Deoliveira a écrit :
> > Question for martin. What exactly is the jar collector used for?
>
> A convenience tools for putting all JAR in a single location (the "target"
> directory) at a time the mavan-assembly plugin was not w
Justin Deoliveira a écrit :
> Question for martin. What exactly is the jar collector used for?
A convenience tools for putting all JAR in a single location (the "target"
directory) at a time the mavan-assembly plugin was not working as I expected.
Should now be removed in favor of maven-assembly.
On Tue, 2007-04-24 at 16:26 -0700, Jody Garnett wrote:
> Please upgrade to Maven 2.0.5 - thanks to everyone who helped test the
> alternatives today.
>
> News announcement here:
> -
> http://docs.codehaus.org/display/GEOTOOLS/2007/04/24/Upgrade+to+Maven+2.0.5
For your matrix,
build works with m
This change suffers from:
1) No justification: There has been no well defined explanation as to
why it was necessary to change the core build tool. (i.e. no one other
than Martin answered Andrea's repeated questions, and Martin said he
could downgrade).
2) No warning: while there has been discuss
20 matches
Mail list logo
