Spring Security
  1. Spring Security
  2. SEC-1541

CLONE -all modules depend directly on commons logging

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 3.0.2
    • Fix Version/s: None
    • Component/s: Build and Admin
    • Labels:
      None

      Description

      Please remove commons logging dependency from all modules except of core. All modules will still be commons logging dependent and exclusion of commons logging in projects using slf4j will be simpler.

      Spring framework uses same system.

        Activity

        Hide
        Luke Taylor added a comment -

        Ok, leaving aside commons-logging for a moment, let me rephrase my question in two parts.

        1. What is your definition of a "compile" dependency?
        2. How will you know what the "compile" dependencies of those projects are in order to raise those jira issues? In fact, how do you know what the "compile" dependencies of your own projects are if you are using maven?

        Maven always adds transitive dependencies to the compile classpath, so you have no way of working out what you actually require to compile. Since that's the case with maven in general, I'm not really bothered about commons-logging. As I mentioned in the original issue, we will not be using maven for future releases. In the current gradle build, we compile against commons-logging, but run the tests against slf4j/logback. We also have transitive dependency resolution disabled for the compile task, so the the listed dependencies actually are those which would be required to run javac against the code.

        Show
        Luke Taylor added a comment - Ok, leaving aside commons-logging for a moment, let me rephrase my question in two parts. 1. What is your definition of a "compile" dependency? 2. How will you know what the "compile" dependencies of those projects are in order to raise those jira issues? In fact, how do you know what the "compile" dependencies of your own projects are if you are using maven? Maven always adds transitive dependencies to the compile classpath, so you have no way of working out what you actually require to compile. Since that's the case with maven in general, I'm not really bothered about commons-logging. As I mentioned in the original issue, we will not be using maven for future releases. In the current gradle build, we compile against commons-logging, but run the tests against slf4j/logback. We also have transitive dependency resolution disabled for the compile task, so the the listed dependencies actually are those which would be required to run javac against the code.
        Hide
        jieryn added a comment -

        Q1. What is your definition of a "compile" dependency?
        A1. Some module other than the current one which is required for this module to be compiled. Most of the time this will be because you issued an import org.apache.commons.logging.Log; statement, as a topical example.

        Q2. How will you know what the "compile" dependencies of those projects are in order to raise those jira issues? In fact, how do you know what the "compile" dependencies of your own projects are if you are using maven?
        A2. I don't see how this is relevant, but ever the teacher, there are lots of easy ways to determine this. It's quite trivial to ensure that every import can be found in one of the dependencies which are immediately referenced in the POM. Maven provides a nice plugin which assists in this process, see http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html

        Maven does not always add transitive dependencies to the compile classpath. For example, junit is a frequent dependency of a most projects, and yet it will not be added to the compile classpath. It will be added to the test-compile classpath. I could go on and on..

        Use whatever deployment mechanism you want, but as long as you are going to make POMs available to the general community, then you should get them correct. I think it's a shame that your team would abandon Maven, but perhaps it's based on obvious misunderstandings and misapprehensions about how Maven works, as is evident in this JIRA; but again, use whatever deployment mechanism you wish.. Please don't introduce problems for majority of us.

        So I recommend we either delete the POMs all together, or get them right. Wrong/bad information is worse than no information.

        Show
        jieryn added a comment - Q1. What is your definition of a "compile" dependency? A1. Some module other than the current one which is required for this module to be compiled. Most of the time this will be because you issued an import org.apache.commons.logging.Log; statement, as a topical example. Q2. How will you know what the "compile" dependencies of those projects are in order to raise those jira issues? In fact, how do you know what the "compile" dependencies of your own projects are if you are using maven? A2. I don't see how this is relevant, but ever the teacher, there are lots of easy ways to determine this. It's quite trivial to ensure that every import can be found in one of the dependencies which are immediately referenced in the POM. Maven provides a nice plugin which assists in this process, see http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html Maven does not always add transitive dependencies to the compile classpath. For example, junit is a frequent dependency of a most projects, and yet it will not be added to the compile classpath. It will be added to the test-compile classpath. I could go on and on.. Use whatever deployment mechanism you want, but as long as you are going to make POMs available to the general community, then you should get them correct. I think it's a shame that your team would abandon Maven, but perhaps it's based on obvious misunderstandings and misapprehensions about how Maven works, as is evident in this JIRA; but again, use whatever deployment mechanism you wish.. Please don't introduce problems for majority of us. So I recommend we either delete the POMs all together, or get them right. Wrong/bad information is worse than no information.
        Hide
        jieryn added a comment -

        I forgot to mention,

        $ git clone git://git.springsource.org/spring-security/spring-security.git
        $ fgrep -r 'import org.apache.commons.logging.Log' spring-security | wc
            192     384   27160
        $ echo "Obviously there is a compile-time dependency on commons-logging."
        
        Show
        jieryn added a comment - I forgot to mention, $ git clone git: //git.springsource.org/spring-security/spring-security.git $ fgrep -r ' import org.apache.commons.logging.Log' spring-security | wc 192 384 27160 $ echo "Obviously there is a compile-time dependency on commons-logging."
        Hide
        Luke Taylor added a comment -

        Ok, so your definition is basically the one I already mentioned - javac's requirements. This may also include dependencies which contain classes which you do not use anywhere in your code (because of inheritance issues, for example). So from my perspective, the simplest way of working out whether your compile-time dependencies are adequate is to run the compiler against them. That's what we do now, and you can't do it with maven.

        The existing build poms will be deleted, and the deployed ones will be generated individually for each module, functioning purely as dependency metadata.

        Show
        Luke Taylor added a comment - Ok, so your definition is basically the one I already mentioned - javac's requirements. This may also include dependencies which contain classes which you do not use anywhere in your code (because of inheritance issues, for example). So from my perspective, the simplest way of working out whether your compile-time dependencies are adequate is to run the compiler against them. That's what we do now, and you can't do it with maven. The existing build poms will be deleted, and the deployed ones will be generated individually for each module, functioning purely as dependency metadata.
        Hide
        jieryn added a comment -

        I think you're unable to fully grasp the words that I'm putting down here, let alone an advanced argument for correctness. The POMs should be deleted, and I'd like to see the JIRA or revision which does this please..

        Show
        jieryn added a comment - I think you're unable to fully grasp the words that I'm putting down here, let alone an advanced argument for correctness. The POMs should be deleted, and I'd like to see the JIRA or revision which does this please..

          People

          • Assignee:
            Luke Taylor
            Reporter:
            jieryn
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: