[metrics-bugs] #23549 [Metrics/Website]: Move ExoneraTorServlet to metrics-web

[Tor Bug Tracker & Wiki]

#23549: Move ExoneraTorServlet to metrics-web
-----------------------------+------------------------------
 Reporter:  karsten          |          Owner:  metrics-team
     Type:  enhancement      |         Status:  needs_review
 Priority:  Medium           |      Milestone:
Component:  Metrics/Website  |        Version:
 Severity:  Normal           |     Resolution:
 Keywords:  metrics-2018     |  Actual Points:
Parent ID:                   |         Points:
 Reviewer:                   |        Sponsor:
-----------------------------+------------------------------
Changes (by karsten):

 * status:  needs_information => needs_review


Comment:

 I finally put some more thoughts into this ticket after spending some time
 on the related #24296.

 I'm less convinced that moving classes from the ExoneraTor repository to
 the metrics-lib repository in order to use them in Tor Metrics (and
 possibly in a stand-alone version of ExoneraTor) is the best way to go.

 Taking a step back, there are plenty of ways to reuse classes from the
 ExoneraTor repository in Tor Metrics:

  - Copy: We can just copy classes over. Well, okay, let's not.
  - Monorepo: This is an idea that crossed my mind the other week and that
 I still think is a good idea. However, let's not do that yet. Even though
 it would solve this problem.
  - Submodule: We could pull in ExoneraTor as Git submodule in Tor Metrics.
 Not my favorite.
  - Shared library: This is the metrics-lib plan discussed above. Would
 work, but we'd basically advance the technical interface between
 ExoneraTor backend and frontend to a public interface. I don't think we
 need to do this, and we should try to avoid the added effort for
 maintaining a public interface if we can. Note that we can always do that
 later, if we think it's a good idea.
  - Release as dependency: This was iwakeh's idea above, and I think I like
 that better than the shared library plan, for the reason stated above.
 However, `exonerator-2.1.0.jar` is 6.3M large, because it contains all of
 ExoneraTor's dependencies. It's a fat jar.
  - Thin jar as dependency: Based on iwakeh's idea (or maybe this was their
 idea all the time), provide another thin jar file together with
 ExoneraTor's next release and pull that into Tor Metrics. This jar would
 only contain ExoneraTor's own classes and resources but without all those
 other classes (Apache Commons, Jackson, Jetty, Logback, etc.). However, it
 would contain all of ExoneraTor's classes, not a subset. We could use the
 very same approach for Metrics Bot reusing Onionoo's document classes. But
 let's see first if it works for ExoneraTor.
  - What else did I miss?

 Thoughts? Setting to needs_review for the concept, not for actual code.

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