Re: [josm-dev] New GPX implementation

2009-05-05 Thread Apollinaris Schoell
> compatible. I'm not in a hurry to switch to 1.6 but we'll do it at > *some* point and I am interested in finding out what that point is > going > to be. Mac OS Tiger, Leopard 32bit have no 1.6 ___ josm-dev mailing list josm-dev@openstreetmap.org h

Re: [josm-dev] New GPX implementation

2009-05-05 Thread Ulf Lamping
Ľubomír Varga schrieb: > I like system "not reinventing wheel". If josm will more rely on third party > code, it will gain better maintability, stability and less code. Only > drawback is in relying on "third party code". Well, there are drawbacks like bugs in third party code that you can't ea

Re: [josm-dev] New GPX implementation

2009-05-05 Thread Richard Fairhurst
Frederik Ramm wrote: > But while we're at it, give us some reasons why we need to remain > 1.5 compatible. I'm not in a hurry to switch to 1.6 but we'll do it > at *some* point and I am interested in finding out what that point > is going to be. 1.6 isn't available for PowerPC Macs, FWIW. Appl

[josm-dev] R: R: R: FW: [OSM-newbies] JOSM problems - is it just me?

2009-05-05 Thread Fabrizio Carrai
It has been closed. The problem has been considered to belong to Java and not to JOSM (no fix). I'll keep continue to update the Java VM... :-( F. > -Messaggio originale- > Da: josm-dev-boun...@openstreetmap.org > [mailto:josm-dev-boun...@openstreetmap.org]per conto di Fabrizio Carrai > I

Re: [josm-dev] New GPX implementation

2009-05-05 Thread Brett Henderson
Frederik Ramm wrote: > We don't normally develop stuff "for future use" because in 90% of cases > it gets never used and just bloats the code. > > I'm not into GPX a lot; I load traces into JOSM and that's it. So if > those who use GPX more than I do all say "hooray, we've been waiting for > the

Re: [josm-dev] New GPX implementation

2009-05-05 Thread Russ Nelson
Ľubomír Varga writes: > I like system "not reinventing wheel". If josm will more rely on third party > code, it will gain better maintability, stability and less code. Only > drawback is in relying on "third party code". There's nothing *wrong* with third party code. The problem is having a

Re: [josm-dev] New GPX implementation

2009-05-05 Thread Frederik Ramm
Hi, Henrik Niehaus wrote: > At the moment JOSM puts most of the GPX elements into a map like > (tag_name, value). If the user decides to write the file back to disk > the order of the elements is random. So there is a good chance that you > get an invalid file. That could be trivially fixed by us

Re: [josm-dev] New GPX implementation

2009-05-05 Thread Ľubomír Varga
I like system "not reinventing wheel". If josm will more rely on third party code, it will gain better maintability, stability and less code. Only drawback is in relying on "third party code". I suggest to make some prototyping done with that libraty, to get familiar with it and than decide if

Re: [josm-dev] New GPX implementation

2009-05-05 Thread Frederik Ramm
Hi, Russ Nelson wrote: > > Portability in terms of runnable on Win, Mac, Linux? JAXB is pure Java > > and depends on Java 1.5, so it should run on any platform, which > > supports Java 1.5 or better. > > Sounds like this patch would cause JOSM to not work under Java 1.5. I > suggest that we n

Re: [josm-dev] New GPX implementation

2009-05-05 Thread Russ Nelson
Henrik Niehaus writes: > Russ Nelson schrieb: > > Henrik Niehaus writes: > > > No one interested? > > > > Is JAXB a separate library? How does this extra code affect the > > portability? > > > > If you use Java <= 1.5, JAXB is a separate library. Java 1.6 includes a > JAXB implementa

Re: [josm-dev] New GPX implementation

2009-05-05 Thread Frederik Ramm
Henrik, > No one interested? I read your post and I didn't like it, but did not want to spoil your fun. First of all, JOSM is not a playground for "trying out new technologies". If there's a good reason for introducing something new (and the increased complexity that comes with it) then fine.

Re: [josm-dev] New GPX implementation

2009-05-05 Thread Henrik Niehaus
Russ Nelson schrieb: > Henrik Niehaus writes: > > No one interested? > > Is JAXB a separate library? How does this extra code affect the > portability? > If you use Java <= 1.5, JAXB is a separate library. Java 1.6 includes a JAXB implementation. Portability in terms of runnable on Win, Mac,

Re: [josm-dev] New GPX implementation

2009-05-05 Thread Greg Troxel
Henrik Niehaus writes: >> Cons: >> 1. JOSM depends on JAXB -> 5 jars with a total size of 1MiB (for JDK >> 1.5. JDK 1.6 comes with JAXB) >> 2. It's a big patch and might need some time to get everything >> (including plugins) back to work >> 3. New bugs, which made their way in the new implement

Re: [josm-dev] New GPX implementation

2009-05-05 Thread Russ Nelson
Henrik Niehaus writes: > No one interested? Is JAXB a separate library? How does this extra code affect the portability? -- --my blog is athttp://blog.russnelson.com Cloudmade supports http://openstreetmap.org/ 521 Pleasant Valley Rd. | +1 315-323-1241 Potsdam, NY 13676-3213 | Sh

Re: [josm-dev] New GPX implementation

2009-05-05 Thread Henrik Niehaus
Henrik Niehaus schrieb: > Hi JOSM coders, > > I came across several problems and feature requests for GPX files while > looking at the bug tracker and reading this list. So I decided to learn > a new technology and gave JAXB a try. The result is a JOSM, which fully > supports GPX 1.0 and 1.1, beca

Re: [josm-dev] Updating Plugin handling (#2530)

2009-05-05 Thread Ævar Arnfjörð Bjarmason
On Tue, May 5, 2009 at 4:24 PM, Dirk Stöcker wrote: > Hello, > > is there someone here who has time and feels like fixing following bug: > http://josm.openstreetmap.de/ticket/2530 > > Essentially this is removing the HTML/XML loading and replacing it with > loading the manifest based file at http:

[josm-dev] Updating Plugin handling (#2530)

2009-05-05 Thread Dirk Stöcker
Hello, is there someone here who has time and feels like fixing following bug: http://josm.openstreetmap.de/ticket/2530 Essentially this is removing the HTML/XML loading and replacing it with loading the manifest based file at http://josm.openstreetmap.de/plugin (i.e. unifying the handling of l