Spring Roo
  1. Spring Roo
  2. ROO-3107

"web mvc setup" leads to "Referenced file contains errors..." in Spring config files

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Duplicate
    • Affects Version/s: 1.2.1.RELEASE
    • Fix Version/s: 1.2.2.RELEASE
    • Component/s: @ ROO SHELL, WEB MVC
    • Labels:
    • Environment:
      OS: Win XP
      STS version: 2.9.1
      Roo version: 1.2.1
      JDK: 1.7.0_03-b05

      Description

      Running "web mvc setup" leads to "Referenced file contains errors..." errors in Spring config file (applicationContext-jpa.xml) from within STS.

      applicationContext-jpa.xml
      <?xml version="1.0" encoding="UTF-8"?>
      <beans:beans xmlns:beans="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.springframework.org/schema/data/jpa"
        xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/data/jpa http://www.springframework.org/schema/data/jpa/spring-jpa.xsd">
      
        <repositories base-package="com.springsource.pizzashop" />
      
      </beans:beans>
      
      Error text

      Multiple annotations found at this line:

      • Referenced file contains errors (jar:file:/C:/Documents and Settings/[username]/.m2/repository/org/springframework/spring-context/3.1.0.RELEASE/spring-
        context-3.1.0.RELEASE.jar!/org/springframework/context/config/spring-context-3.0.xsd). For more information, right click on the message in the Problems View and select "Show Details..."
      • Referenced file contains errors (jar:file:/C:/Documents and Settings/[username]/.m2/repository/org/springframework/spring-beans/3.1.0.RELEASE/spring-beans-3.1.0.RELEASE.jar!/
        org/springframework/beans/factory/xml/spring-beans-3.0.xsd). For more information, right click on the message in the Problems View and select "Show Details..."
      • Referenced file contains errors (jar:file:/C:/Documents and Settings/[username]/.m2/repository/org/springframework/spring-beans/3.1.0.RELEASE/spring-beans-3.1.0.RELEASE.jar!/
        org/springframework/beans/factory/xml/spring-tool-3.0.xsd). For more information, right click on the message in the Problems View and select "Show Details..."

      I managed to get rid of the error messages by changing the spring-data-jpa version in pom.xml from 1.0.2.RELEASE to 1.1.0.BUILD-SNAPSHOT as suggested here: http://forum.springsource.org/showthread.php?122577-XML-Validation-Problems-A-schema-cannot-contain-two-global-components-with-the-same&highlight=Referenced+file+contains+errors.

      It seems obvious to me that Roo should update the maven project file automatically with appropriate versions that do not cause this kind of problem.

        Issue Links

          Activity

          Hide
          Alan Stewart added a comment -

          I've already updated Spring Data JPA to the current released version 1.0.3 in ROO-3062. As soon as 1.1.0 is available I will update the dependency

          Show
          Alan Stewart added a comment - I've already updated Spring Data JPA to the current released version 1.0.3 in ROO-3062 . As soon as 1.1.0 is available I will update the dependency
          Hide
          Gary White added a comment -

          Alan,

          It's all well and good that changing the spring-data-jpa version in the pom resolves the immediate problem in individual projects but it does nothing to address the bigger systemic problem of the current Roo release (as well as some other earlier releases so I've been told) creating projects that have a dependency that causes this error.

          I saw your comment about supposedly not being able to do anything in the Roo code and therefore taking up the issue with STS or the Spring Framework forums. The bottom line is that Roo, STS and the Spring Framework are all Springsource products and should be integrated/tested to the point where this kind of problem doesn't occur. I find it hard to believe that a Roo release is made without at least one person on the Roo team creating a project and ensuring that this kind of error doesn't show up in STS.

          I understand that you're probably dealing with a significant workload and are just trying to deal with individual issues as best as you can so that you can move on and productively address a larger number of issues but this really does need to be addressed in the larger context of having Springsource products play well with each other before they are pushed out of the door. At the very minimum, a simple bug patch should be immediately released that uses the spring-data-jpa 1.0.3.RELEASE version in the pom. This type of error should not be happening with released products.

          Thanks,
          Gary

          Show
          Gary White added a comment - Alan, It's all well and good that changing the spring-data-jpa version in the pom resolves the immediate problem in individual projects but it does nothing to address the bigger systemic problem of the current Roo release (as well as some other earlier releases so I've been told) creating projects that have a dependency that causes this error. I saw your comment about supposedly not being able to do anything in the Roo code and therefore taking up the issue with STS or the Spring Framework forums. The bottom line is that Roo, STS and the Spring Framework are all Springsource products and should be integrated/tested to the point where this kind of problem doesn't occur. I find it hard to believe that a Roo release is made without at least one person on the Roo team creating a project and ensuring that this kind of error doesn't show up in STS. I understand that you're probably dealing with a significant workload and are just trying to deal with individual issues as best as you can so that you can move on and productively address a larger number of issues but this really does need to be addressed in the larger context of having Springsource products play well with each other before they are pushed out of the door. At the very minimum, a simple bug patch should be immediately released that uses the spring-data-jpa 1.0.3.RELEASE version in the pom. This type of error should not be happening with released products. Thanks, Gary
          Hide
          Alan Stewart added a comment -

          We test all our samples in STS prior to releasing each version of Roo and 1.2.1 was no exception, so I don't know where you got your information from but it is inaccurate. We also have coded classes like AbstractShell so that there is backward compatibility with previous versions of STS as well.

          Show
          Alan Stewart added a comment - We test all our samples in STS prior to releasing each version of Roo and 1.2.1 was no exception, so I don't know where you got your information from but it is inaccurate. We also have coded classes like AbstractShell so that there is backward compatibility with previous versions of STS as well.
          Hide
          Gary White added a comment - - edited

          I made my comments based on the fact that this error actually exists and not from information obtained from any external source; if there was adequate testing then the problem wouldn't exist. I don't know which combination of Roo/STS releases caused this to happen or the sequencing of those releases but the problem does exist. If a new Roo release caused this problem in an existing STS release, then that tells me that it was not properly tested by the Roo team. If the problem occurred as a result of a new STS release then the issue of which team (STS vs Roo) should have been responsible for testing/fixing the problem is somewhat less clear but what is clear is that both products are produced by SpringSource and someone at SpringSource should be on top of integration testing to make sure that this type of error doesn't happen. The bottom line is that this type of error can and should be prevented in production releases regardless of which specific product release is responsible.

          There is some kind of systemic gap that is allowing this to happen. It seems to me that there should be better coordination between the STS and Roo teams but--not having visibility into the internal processes/interactions--that is just speculation on my part. All that I'm saying is that there is a hole somewhere that allowed this problem to slip through. Do you have any suggestions on how to address this?

          Thanks for your assistance

          Show
          Gary White added a comment - - edited I made my comments based on the fact that this error actually exists and not from information obtained from any external source; if there was adequate testing then the problem wouldn't exist. I don't know which combination of Roo/STS releases caused this to happen or the sequencing of those releases but the problem does exist. If a new Roo release caused this problem in an existing STS release, then that tells me that it was not properly tested by the Roo team. If the problem occurred as a result of a new STS release then the issue of which team (STS vs Roo) should have been responsible for testing/fixing the problem is somewhat less clear but what is clear is that both products are produced by SpringSource and someone at SpringSource should be on top of integration testing to make sure that this type of error doesn't happen. The bottom line is that this type of error can and should be prevented in production releases regardless of which specific product release is responsible. There is some kind of systemic gap that is allowing this to happen. It seems to me that there should be better coordination between the STS and Roo teams but--not having visibility into the internal processes/interactions--that is just speculation on my part. All that I'm saying is that there is a hole somewhere that allowed this problem to slip through. Do you have any suggestions on how to address this? Thanks for your assistance
          Hide
          Gary White added a comment -

          I just wanted to note that I created this issue https://jira.springsource.org/browse/ROO-3110 to address the testing aspect of this.

          Show
          Gary White added a comment - I just wanted to note that I created this issue https://jira.springsource.org/browse/ROO-3110 to address the testing aspect of this.
          Hide
          Gary White added a comment - - edited

          In reference to your comment about testing samples in STS, do you also test creating new projects (as opposed to existing samples)? It seems to me that the problem is (at least in this instance) that the POM that is created contains the version mismatch that is causing the errors in STS. Testing a previously created project might not detect this since the POM would have been created by a different code base and therefore would not have this mismatch.

          I would think that testing of newly created Roo projects should take place prior to the release of new Roo releases as well as STS releases since it seems this type of problem might be triggered by either.

          Thanks again

          Show
          Gary White added a comment - - edited In reference to your comment about testing samples in STS, do you also test creating new projects (as opposed to existing samples)? It seems to me that the problem is (at least in this instance) that the POM that is created contains the version mismatch that is causing the errors in STS. Testing a previously created project might not detect this since the POM would have been created by a different code base and therefore would not have this mismatch. I would think that testing of newly created Roo projects should take place prior to the release of new Roo releases as well as STS releases since it seems this type of problem might be triggered by either. Thanks again

            People

            • Assignee:
              Alan Stewart
              Reporter:
              Gary White
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: