On Thu, 7 May 2009, Henrik Niehaus wrote:
>>> 1. If we take all three steps you suggested, we have the same situation
>>> as today. There will be many spots in JOSM, which will change, because
>>> the old code has to be removed and the new merged into JOSM
>>
>> No. We would not remove old code no
Dirk Stöcker schrieb:
> On Thu, 7 May 2009, Henrik Niehaus wrote:
>
>> 1. If we take all three steps you suggested, we have the same situation
>> as today. There will be many spots in JOSM, which will change, because
>> the old code has to be removed and the new merged into JOSM
>
> No. We would
On Thu, 7 May 2009, Henrik Niehaus wrote:
> 1. If we take all three steps you suggested, we have the same situation
> as today. There will be many spots in JOSM, which will change, because
> the old code has to be removed and the new merged into JOSM
No. We would not remove old code now. Would be
Hi.
Just for the reference: my TCX-support plugin was based on JAXB from the
start and includes the necessary JABX libs for java 1.5.
So far nobody complained about the large download size or anything... but I
guess I'm the only one who uses it ;)
Anyway, JAXB is quite solid. I'm using it for ev
Frederik Ramm writes:
> I don't, however, see a pressing need to support any and all extended
> GPX features.
Actually, JOSM makes a fine GPX editor. Great for removing those
birds nests when you stopped for lunch.
--
--my blog is athttp://blog.russnelson.com
Cloudmade supports http://op
Hi,
Henrik Niehaus wrote:
> The use case of supporting the "GPX standard" is equal to the use case
> of supporting GPX, in my opinion. Do it right or leave it be.
I was asking because it seemed to me that supporting a tiny subset of
the GPX standard is, in my eyes, sufficient for JOSM - load a
Frederik Ramm schrieb:
> 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.
>
Ľubomír Varga schrieb:
> It will run everywhere. Only "problem" with portability is that, that on java
> 1.5 systems is some aditional lib (packable into josm.jar) needed. afaik. But
> I see it like handicap, because if Iam not wrong, that lib has about 7 MB.
It's only 1 MB and can be packaged
Petr Nejedlý writes:
> Greg Troxel napsal(a):
>> But, if someone just has to download a jar and add it to a command line,
>> that doesn't seem like a big deal, even if it is 7 MB.
>>
> It _is_ a big deal in case the change brings no benefit to most of the
> users.
> And I would even expect th
Greg Troxel napsal(a):
> But, if someone just has to download a jar and add it to a command line,
> that doesn't seem like a big deal, even if it is 7 MB.
>
It _is_ a big deal in case the change brings no benefit to most of the
users.
And I would even expect that it would make performance and m
1.6 isn't available for PowerPC Macs, FWIW. Apple haven't made a PPC Mac
since 2006. I still use PPC for both my main machines (but then I'm not a
JOSM user so that may be moot).
This is in my view a sufficient reason to insist that everything work
with 1.5.
But, if someone just has to dow
It will run everywhere. Only "problem" with portability is that, that on java
1.5 systems is some aditional lib (packable into josm.jar) needed. afaik. But
I see it like handicap, because if Iam not wrong, that lib has about 7 MB.
That is realy big think to bundle with josm. I hope Iam wrong...
> 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
Ľ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
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
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
Ľ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
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
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
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
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
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.
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,
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
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
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
26 matches
Mail list logo