Thanks Casey. We definitely need more testing. At this point I've just done some light smoke testing with full dev to ensure nothing obvious is broken (should cover ES though). I imagine we'll need to test Solr as you suggest and also test all our scripts with an actual use case to ensure we haven't introduced runtime classpath issues. We have also noticed some regressions while using Stellar in the enrichment topology so it might be a good time to create a test suite for that. I believe Mike Miklavcic is currently working on that.
On Mon, Jun 3, 2019 at 11:02 AM Casey Stella <ceste...@gmail.com> wrote: > This looks good to me, honestly. Anything to make the build more > understandable and help find classpath issues easier is a good idea IMO. > > Just curious, did you test that PR in both solr and ES (you added an > exclude in the ES portion of the code) and did you spin it up in full-dev > (to ensure ambari doesn't have any dependencies on the jar names)? > > Other than that, I'm +1 to the effort! > > On Mon, Jun 3, 2019 at 8:55 AM Ryan Merriman <merrim...@gmail.com> wrote: > > > I recently opened a PR <https://github.com/apache/metron/pull/1436> that > > has potential to significantly change (for the better in my opinion) the > > way our Maven build process works. I want to highlight this and get any > > feedback on potential issues that may come with this change. > > > > I frequently run into the classpath version issues (especially with the > > recent module reorganization work) and find them extremely challenging to > > troubleshoot. I believe we have found the root cause (from the PR > > description): > > > > "When a module that uses the shaded plugin without a classifier is added > to > > another module as a dependency: > > > > 1. Any Maven excludes added to that dependency are ignored > > 2. The Maven dependency:tree tool does not accurately report the > transitive > > dependencies pulled in by that dependency" > > > > After making this change, a number of classpath version problems popped > up > > as expected. However they are now easy to track down and resolve. > > > > Does anyone have any concerns with making this change? Are there things > > I'm not thinking of? > > >
