[josm-dev] livegps plugin update for new gpsd 2.9x (future 3.0) protocol

[Gleb Smirnoff]

On Wed, Jun 09, 2010 at 09:29:16AM +0200, Dirk St?cker wrote:
D> > F> > Can you please comment on including foreign code in plugin? What is the
D> > F> > correct procedure? The situation seems similar to the org.apache.tools.bzip2
D> > F> > in the core josm repo.
D> > F>
D> > F> The JOSM plugin installer does not support dependencies on third-party
D> > F> libraries so the way you did it is probably the one that is easiest for
D> > F> users.
D> >
D> > When I run 'svn up' on josm I see some messages like "fetching external
D> > item". May be I misunderstand this... doesn't this mean some link to
D> > external repo?
D> 
D> You have 3 ways:
D>   * use svn:externals to link directly to an extern SVN and import the
D>     parts you need (see in core).

The json.org doesn't seem to have public SVN :(

D>   * Make a lib directory and copy the .jar into the build (see e.g.
D>     dataimport plugin)

I suppose this way is OKAY in Java world, which I am not used to yet. :
Should I proceed this way?

D>   * Copy the source directly into src. This is fine when you strip them
D>     down to bare minimum and modify them. If not, the first two approaches
D>     seem to be better regarding updates.

Why does 3) require stripping to bare minimum? I'd prefer to import the
library w/o modifications. We would have problems if we encounter bug in
it, we won't be able to tell whether this is due to our modification or not.

I am used to a practice when foreign source is maintained in $REPO/vendor,
where new releases of foreign source are imported. And this code doesn't
participate in build. Then it is 'svn merge'd to $REPO/smth/smth/foo and
optionally modified, if needed, and then used in build. Looks like there is
no such practice in OSM. Can we introduce it? Would be there a benefit
comparing to committing .jar?

-- 
Totus tuus, Glebius.