kriegaex commented on PR #137: URL: https://github.com/apache/xalan-java/pull/137#issuecomment-1837754627
> If you can describe how a _commons module should be defined/bounded That would be pretty easy to introduce. We could either seed it now, simply moving the version base class there as a showcase, similar to how those classes are already showcases for unit and integration test. Other duplicate code could be moved there later, step by step or in one big PR. The logic is that each module depending on something in the common module would declare a dependency on it and make sure to include the common classes in its binary and source JARs. (Feasible, but probably a bad idea, see below.) Or, even easier, we could also publish the common module to Maven Central along with xalan, serializer, samples, and it would be pulled into their Maven or Gradle builds automatically as a transitive dependency. I think, the latter alternative is clearly preferable, because otherwise the common classes would be duplicated into serializer and xalan again, which would cause duplicate class warnings if users decide to shade out artifacts into theirs and also have conflict potential if a user accidentally uses e.g. Serializer 2.7.7 and Xalan 2.7.8. -- 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. To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
