Ralph,
Thanks for the explanation. Is there a strategy for projects that have
both brought in transitively? Hunting down class name conflicts in a
multi-layered dependency tree was one of the reasons that I got
interested in the subject, and I haven't found a satisfying solution to
it yet.
Paul
On
On 3/21/14, 8:58 AM, sebb wrote:
> Note that sanselan was renamed as commons imaging. However the package
> names were also changed so I'm not sure why they are shown as
> duplicates. sanselan: org.apache.sanselan imaging:
> org.apache.commons.imaging Perhaps the information has been derived
> from
You may want to filter out small files, or common file name
conventions: e.g.
https://github.com/apache/accumulo/blob/trunk/maven-plugin/src/it/plugin-test/postbuild.groovy
and
https://github.com/apache/maven-plugins/blob/trunk/maven-invoker-plugin/src/it/script-additional-vars/src/it/groovy/postb
In the case of logging-log4j2 the package and class names are duplicated with
log4j to provide a bridge so that code does not need to be rewritten to
upgrade. However, if you look at the line counts you will see that they are not
the same as the classes are very different.
Ralph
On Mar 20, 20
On 21 March 2014 04:49, Pawel Slusarz wrote:
> Greetings,
>
> When looking at the Apache SF Java projects as a group, I noticed that a
> large number of projects have duplicate class names, ie
> both openejb and tomee have a class named
> jug.client.command.api.AbstractCommand
>
> When edge cases,
Greetings,
When looking at the Apache SF Java projects as a group, I noticed that a
large number of projects have duplicate class names, ie
both openejb and tomee have a class named
jug.client.command.api.AbstractCommand
When edge cases, ie test.Foo and tomcat55, tomcat60, tomcat70 get
eliminated
