merrimanr commented on issue #1436: METRON-2149: Shaded jar classifier is not consistent URL: https://github.com/apache/metron/pull/1436#issuecomment-508162804 Thanks for the feedback. A module that includes Stellar functions is not necessarily a problem. The reason I focused on stellar-common is because it contains a substantial amount of custom code with specific dependency versions that often do not line up with versions required by other 3rd party dependencies (HBase, etc). Moving all Stellar functions to stellar-common is an option but I don't think it's necessary right now. We may want to do this for some classes but it can be done on a case-by-case basis as conflicts arise. I think the important thing is to isolate stellar-common now since we know there are several conflicts and have a strategy in place for when conflicts in other modules happen. The more extreme option would be to move all Stellar code to their own separate modules but I think that's overkill. I agree with your approach of relocating core libraries and marking others as `provided` where appropriate. That makes sense to me. For the case where a module depends on another module that uses the shade plugin and uber classifier, would we just mark that dependency as provided? For example, if a module depends on stellar-common, stellar-common would be set to provided. This way we wouldn't need to exclude dependencies that are rewritten. This would also mean we need to go with the option of adding the uber jars to the classpath separately (option 2 above) but I think that is the correct approach anyways.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
