[tor-bugs] #20564 [Metrics]: Add Jenkins configuration for running metrics-lib's unit tests and producing a .jar file

[Tor Bug Tracker & Wiki]

#20564: Add Jenkins configuration for running metrics-lib's unit tests and
producing a .jar file
-------------------------+---------------------
 Reporter:  karsten      |          Owner:
     Type:  enhancement  |         Status:  new
 Priority:  Medium       |      Milestone:
Component:  Metrics      |        Version:
 Severity:  Normal       |     Resolution:
 Keywords:               |  Actual Points:
Parent ID:               |         Points:
 Reviewer:               |        Sponsor:
-------------------------+---------------------

Comment (by iwakeh):

 Replying to [comment:3 karsten]:
 > ...
 >
 > My preferred approaches are: 3, 1, 4, 2.

 My list of preferences is 1, 3.  Numbers two and four I would rule out.
 Number two for obvious administration overhead and number four would cause
 trouble when developing: dependencies for the sub-module have to be
 provided and it is awkward to refer to the sub-module and depend on a
 release at the same time.

 The addition of descriptor-<version>.jar as in suggestion 1. shouldn't
 cause any problems, I think.  After all linux kernel development adds way
 bigger and more often changing binaries to their git repos without
 problems.  Solution 1. would require the least effort and actually be very
 convenient for development.

 Solution 3. (building all metrics-lib releases in a separate jenkins job)
 is also fine, but requires some more effort than adding a file to the git
 repo.  There shouldn't be a problem with scaling as the job can be
 configured to only keep the few metrics-lib jars and erase all other
 files.

 5. A fifth option is (given that tor-git access is fine) to have a
 metrics-build-resources git repo that contains all non-debian
 dependencies.  Then we also run metrics ant tasks in jenkins, that depend
 on more modern libraries (e.g. checkstyle).  And, the metrics-lib release
 only needs to be added to this repo and not to all other java projects,
 too.

 We could start with solution 1. (without checkstyle etc.) or 5. (incl. all
 code metrics) as these require the least effort. If necessary, 1. could be
 replaced 3. when all jenkins jobs are in place for Metrics' products, but
 that wouldn't address the reason for 5.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20564#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online