Issue2121

I can understand it for the jython-standalone one but there is no reason to emmbed all that in the jython jar. It generates tons of duplicated classes.

There is also something that looks like empty (except for the package-info.class files) guava embedded.

I'm talking about the 2.7b1 release which is not listed in the "Versions" list so I indicated 2.7.

The main one is xml-apis:xml-apis (probably 1.4.01).

Yes that's the 1.4.01 according to org.apache.xmlcommons.Version class.

We would like to make this change, however this requires rethinking our current build process. This will also help in terms of being compatible in the context of Debian packaging.

Defer to 2.7.1

I prepared a very simple solution which has an obvious downside of dependencies being specified in two places.

I'm happy to hear your comments and give it another try, if you give me some guidance on how you want to manage dependencies ideally.

I just realized I did not tackle package name remappings so my patch is incomplete.

We plan to address in 2.7.2 - one of the top priorities of that work is to go to a Gradle build and move to a GitHub based workflow.

First, need to get out the long delayed 2.7.1 of course!

@zyasoft Thanks for the update.

There is now a Gradle build, which if we've done it right, provides the "extreme" solution of making all external dependencies ... external.

The traditional approach will continue to be supported, but we ought to consider reducing our use, having a good reason in each case.

What you call "extreme" solution I call the correct one. If there's ever a need to blend in (shade) external code into your deliverable jars, it should at least have its packages redirected in order to avoid conflict.

I don't disagree.

The JAR built by this approach is here:
https://search.maven.org/artifact/org.python/jython-slim/2.7.2b2/jar

I have successfully cited it as a dependency in (very simple) Maven and Gradle projects. It be interested in knowing whether this hits the spot for more complex uses.

I do not think the original question "why so many", in the other JARs, has been answered. I'd like to reduce this to the absolute minimum in work after 2.7.2. There is perhaps not an absolutely correct way to identify that minimum.