Commons Configuration
  1. Commons Configuration
  2. CONFIGURATION-71

[configuration] Fake "resources" dependency kills Maven2

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:

      Operating System: other
      Platform: Other

      Description

      This dependency:
      <!-- Fake dependency to test loading configuration files from a JAR -->
      <dependency>
      <id>resources</id>
      <version>1.0</version>
      <scope>test</scope>
      </dependency>

      kills Maven 2 because of the transitive nature of Maven2. Maven2 if it has a dependency on a project
      gets all its dependencies as well. So resources of course doesn't exist and fails. Now, currently the
      Maven2 POM is created FROM the maven1 POM.
      http://www.ibiblio.org/maven2/commons-configuration/commons-configuration/1.1/commons-
      configuration-1.1.pom

      We need to either add a Maven2 pom, or just create a fake resources.jar, but in the commons-
      configuration groupId.

        Activity

        David Eric Pugh created issue -
        Hide
        Oliver Heger added a comment -

        Created an attachment (id=16758)
        Patch for project.xml and maven.xml

        This patch removes the resource.jar from the dependencies section in
        project.xml and tweaks maven.xml to explicitely add it to the class path before
        the tests are run.

        I am no maven expert, so not sure if this helps to solve the problem. But the
        dependency that causes trouble will be gone.

        Show
        Oliver Heger added a comment - Created an attachment (id=16758) Patch for project.xml and maven.xml This patch removes the resource.jar from the dependencies section in project.xml and tweaks maven.xml to explicitely add it to the class path before the tests are run. I am no maven expert, so not sure if this helps to solve the problem. But the dependency that causes trouble will be gone.
        Hide
        David Eric Pugh added a comment -

        I think that would do it... Is there a more "java" way to do it though, the only other niggle is that the test
        would now fail under Maven2 because there wouldn't be a maven.xml to do this magic....

        It does seem like our test should not require Maven to do magic.

        Show
        David Eric Pugh added a comment - I think that would do it... Is there a more "java" way to do it though, the only other niggle is that the test would now fail under Maven2 because there wouldn't be a maven.xml to do this magic.... It does seem like our test should not require Maven to do magic.
        Hide
        Oliver Heger added a comment -

        I think I understand what you mean. However I cannot think about a more "java"
        solution ATM.

        This special test case tests whether a configuration file can be loaded from a
        jar. So one would assume that the affected jar must somehow belong to the
        classpath. Maybe it would be possible to do some black magic with custom
        ClassLoaders? But I would rather avoid such a solution (if it works at all).
        Anyone with better ideas?

        If this proposed patch was applied, this would save projects that use Maven2 as
        build tool and specify a dependency to commons-configuration, correct? Well,
        then this would be a first step. For the long run we can think about providing a
        pom for Maven2 (which means that I would have to do some research

        Show
        Oliver Heger added a comment - I think I understand what you mean. However I cannot think about a more "java" solution ATM. This special test case tests whether a configuration file can be loaded from a jar. So one would assume that the affected jar must somehow belong to the classpath. Maybe it would be possible to do some black magic with custom ClassLoaders? But I would rather avoid such a solution (if it works at all). Anyone with better ideas? If this proposed patch was applied, this would save projects that use Maven2 as build tool and specify a dependency to commons-configuration, correct? Well, then this would be a first step. For the long run we can think about providing a pom for Maven2 (which means that I would have to do some research
        Hide
        Oliver Heger added a comment -

        Here is another, more radical approach.

        I checked again the test cases that make use of this resources.jar and came to
        the following result: From configuration's point of view it does not matter
        whether a configuration file is loaded from a jar or elsewhere from the class
        path. In both cases it is simply dealt with a URL (which of course looks
        different). So what we test here is not in the first line our implementation,
        but the Java runtime's ability to handle different types of URLs transparently.
        The affected test cases do not contribute to the code coverage of our test suite.

        So IMHO we could simply remove these tests, thus getting rid of the faked
        dependency at all. Other opinions?

        Show
        Oliver Heger added a comment - Here is another, more radical approach. I checked again the test cases that make use of this resources.jar and came to the following result: From configuration's point of view it does not matter whether a configuration file is loaded from a jar or elsewhere from the class path. In both cases it is simply dealt with a URL (which of course looks different). So what we test here is not in the first line our implementation, but the Java runtime's ability to handle different types of URLs transparently. The affected test cases do not contribute to the code coverage of our test suite. So IMHO we could simply remove these tests, thus getting rid of the faked dependency at all. Other opinions?
        Hide
        David Eric Pugh added a comment -

        +1.. I do feel like our unit tests should NOT get in the way of our delivering code, but instead support
        it... You are right that the test really is not testing Configuration, but testing Java.

        Show
        David Eric Pugh added a comment - +1.. I do feel like our unit tests should NOT get in the way of our delivering code, but instead support it... You are right that the test really is not testing Configuration, but testing Java.
        Hide
        Oliver Heger added a comment -

        Okay, then I will update the tests correspondingly.

        Show
        Oliver Heger added a comment - Okay, then I will update the tests correspondingly.
        Hide
        Oliver Heger added a comment -

        I removed the fake dependency and updated the tests. I also verified that this
        does not have any impact on our test coverage (using clover). So this can be
        closed now!

        Show
        Oliver Heger added a comment - I removed the fake dependency and updated the tests. I also verified that this does not have any impact on our test coverage (using clover). So this can be closed now!
        Henri Yandell made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 37152 12342644
        Henri Yandell made changes -
        Component/s Configuration [ 12311107 ]
        Key COM-2492 CONFIGURATION-71
        Project Commons [ 12310458 ] Commons Configuration [ 12310467 ]
        Affects Version/s 1.1.0 [ 12311676 ]
        Assignee Jakarta Commons Developers Mailing List [ commons-dev@jakarta.apache.org ]
        Henri Yandell made changes -
        Affects Version/s 1.1.0 [ 12311806 ]

          People

          • Assignee:
            Unassigned
            Reporter:
            David Eric Pugh
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development