[josm-dev] livegps plugin update for new gpsd 2.9x (future 3.0) protocol
glebius at glebius.int.ru
Wed Jun 9 08:47:35 BST 2010
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> > 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> 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.
More information about the josm-dev