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? >
