I think most of the work comes from knowing which of our dependencies are truly needed by what at runtime.
An easy first pass would be to ensure junit is a dependency for the integration-tests component and then make that module and its dependencies go into a different directory than our normal library jars. That should get JUnit out of our normal classpath while allowing for the use case that came up prominently last time we wanted to remove it. I think that means we're looking at some pom chances and an update to our assembly for the convenience binary. On Mon, Nov 21, 2016 at 11:16 AM, Stack <st...@duboce.net> wrote: > Sounds good to me Jan and Sean. How much work we talking and what sort of > movement? > Thanks, > S > > On Mon, Nov 21, 2016 at 8:57 AM, Sean Busbey <bus...@apache.org> wrote: > >> In particular, does anyone have a problem with us restructuring our >> assembly so that we break out the dependencies needed for runtime of >> our service processes and those needed for particular tools (like the >> IT tests in the case of junit). >> >> 2.0 seems like a good time to introduce this kind of breaking layout >> change, to me. >> >> On Mon, Nov 21, 2016 at 3:23 AM, Jan Hentschel >> <jan.hentsc...@ultratendency.com> wrote: >> > Hi, >> > >> > >> > >> > Sean Busbey and I had a quick chat about HBASE-16555 and HBASE-12909 >> covering needed dependencies for running the tests. Currently JUnit is >> declared as a compile dependency in the parent POM. Both tickets try to >> change it to test scope. Sean and I try to create a list seperating >> dependencies needed for running the tests and the general runtime >> dependencies and would appreciate some help. Which dependencies are really >> needed as a runtime dependency and which are better scoped for test runs? >> > >> > >> > >> > Jan >> > >> -- busbey
