Hi,
is there a particular reason why batik-all.jar is located
in lib/batik/ and not simply in lib/ ?
Best
Jan
--
Dr. Jan-Oliver WagnerIntevation GmbH, Osnabrück
Amtsgericht Osnabrück, HR B 18998 http://www.intevation.de/
Geschäftsführer: Frank Koorman
Jan,
I think that Stefan was simply trying to add a little organization to the
lib folder. We originally had multiple JAR files for Batik, but now we have
only one.
I would think that the batik-all JAR could no be placed in the /lib folder
and we can delete the /batik folder. But let's check wit
Yep, somehow..
since i was not sure if everything still works after the replacement.
Further there is also needed a change in the ant-built srcipts, to
dismiss the batik folder.
thus.. currently, as everything seems to run as it should, it is rather
a TODO issue???
stefan
Jan-Oliver Wagner s
I've been working on my FeatureCache and I've got a couple of questions
about the FeatureCollection interface.
Three of the methods of the interface return instances of
java.util.Collection. The getFeatures() method and the query() methods
return instances of java.util.List, while the remove() me
The fact that getFeatures and query return a List is probably an
undesirable widening of the API. For maximum flexibility for
implementors, they should all return Collection. This was just an
oversight in the original design.
The reason that remove(Envelope) returns a collection of the remove
On Friday 27 April 2007 17:42, Stefan Steiniger wrote:
> Yep, somehow..
>
> since i was not sure if everything still works after the replacement.
> Further there is also needed a change in the ant-built srcipts, to
> dismiss the batik folder.
>
> thus.. currently, as everything seems to run as it s
CDPN Acquires GPS And Wireless Transportation Development Company!
China Datacom Corp.
Sym: CDPN
Close: $0.065
CDPN, through its subsidiary "Supremacy Intl", acquired all outstanding
shares in General Link Information Systems. General manages, serves and
operates the only GPS vehicle monitoring a
Martin,
This makes perfect sense. Thank you for the clarification. If no one has an
objection I will make a not of it in the Javadoc API. I might also see if I
can refactor the FeatureCollection interface to use java.util.Collection on
the other two methods. This will give me some practice with R
If Jan is working with the batik libraries as part of the effort with the
print plug-in I have no problem removing the directory as long as the loose
ends are taken care of.
I think it is good to fix these little things when we run across them.
Collectively such small efforts will make for a bett
SS,
It's easy to change the FC interface methods return value from List to
Collection n the JUMP CVS codebase.
But you risk breaking a lot of external plugins which have been coded to
the current interface. I don't really see a pressing need to do this,
so I would vote against it.
Sunburned
O.K.
SS
On 4/27/07, Martin Davis <[EMAIL PROTECTED]> wrote:
SS,
It's easy to change the FC interface methods return value from List to
Collection n the JUMP CVS codebase.
But you risk breaking a lot of external plugins which have been coded to
the current interface. I don't really see a pre
I've been unable to locate the null pointer bug in my pluggable renderer
code. I'm going back to write JUnit tests for my classes in
an effort to catch the error, which I should've done in the first place.
However, this is a little easier said than done. One of the
classes I need to test calls the
12 matches
Mail list logo
