Unfortunately the patch does not follow the coding style guide for submitting a patch. Furthermore it uses an IDE specific patch format which i can't proceed via patch command. The best way to produce a patch is to use svn diff on command line. Apart from that i've seen things like this in the code:

private String unused_variable_2;

which i would never accept for a patch, it would make more sense to think about the intention of the variable and name it accordingly.
One other thing has become my interest, cause i saw a thing like this:

private boolean useAllDependencies_no_longer_used;

This variable has already been marked as deprecated and should be handled that way. This means renaming it does not work, cause it will break backward compatibility. If you have the problem that it will contradict with the filtering than the best thing is to bring either a WARNING or may be break the build with an appropriate message which explains the problem for the user with a hint to solve the problem.


Furthermore I think the usage of the filter is a little bit weird, cause you are using type filter which are things like jar, zip. I would think more in the direction of the usual naming conventions maven already has like groupId:artifactId:classifier:version:packaging which will be usable like this.

<excludes>
    <exclude>log4j:log4j:1.2.16::*</exclude>
  <excludes>

After analyzing the problem I figured out that there exist already appropriate filter things like this:
http://maven.apache.org/shared/maven-common-artifact-filters/apidocs/index.html which i think would be the best approach to solve the problem.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

Reply via email to