Maven SCM
  1. Maven SCM
  2. SCM-634

Clearcase provider status keeps displaying "Can't load the scm provider. You need to define a connectionUrl parameter" but connection node is defined.

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.5
    • Fix Version/s: None
    • Labels:
      None
    • Environment:
      Windows
    • Complexity:
      Intermediate
    • Number of attachments :
      1

      Description

      POM has been defined correctly:
      <project>
      ......
      <scm>
      <connection>scm|clearcase|c:\views\tempview\configSpec.txt</connection>
      <developerConnection>scm|clearcase|c:\views\tempview\configSpec.txt</developerConnection>
      </scm>
      ......
      </project>

      Plugin configuration points to "connection". When doing a 'mvn scm:status' keeps telling me "Can't load the scm provider. You need to define a connectionUrl parameter". However I am pointing to a valid configSpec('mvn scm:validate' = success) and connection is defined as shown above.

      ConfigSpec (for completeness) is:
      element * CHECKEDOUT
      element -dir * /main/LATEST
      element * /main/release_1.0/tempview/LATEST
      element * /main/release_1.0/LATEST -mkbranch ac42144_r1.0_t0001
      element * /main/R1.0 -mkbranch release_1.0
      element * /main/

      {created_since(today)}

      -mkbranch release_1.0
      load c:\views\tempview\WCSF\CustomerService

      Cannot do anything with plugin currently because message prevents code from being checked out.

        Activity

        Hide
        Robert Scholte added a comment -

        Issue confirmed (see attached test). The problem is caused by tokening the third part of the connection. Here the code has no idea what the original delimeter was. So it tries both | and :.
        A workaround might be to add a pipe to the URL

         
        <developerConnection>scm|clearcase|c:\views\tempview\configSpec.txt|</developerConnection>
        
        Show
        Robert Scholte added a comment - Issue confirmed (see attached test). The problem is caused by tokening the third part of the connection. Here the code has no idea what the original delimeter was. So it tries both | and : . A workaround might be to add a pipe to the URL <developerConnection> scm|clearcase|c:\views\tempview\configSpec.txt| </developerConnection>
        Hide
        Justin Bleach added a comment - - edited

        Added the pipe to the end of the URL to no avail. Same error on scm:status goal. Running package lifecycle the plugin doesn't even show up in the standard output.

        <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-scm-plugin</artifactId>
        <version>1.5</version>
        <configuration>
        <connectionType>connection</connectionType>
        <excludes>target</excludes>
        </configuration>
        </plugin>

        Is there more concise documentation on how the Maven SCM plugin and providers interact. I'm able to get the source for the plugin but can't find a URL for the source code for the Clear Case provider.

        Show
        Justin Bleach added a comment - - edited Added the pipe to the end of the URL to no avail. Same error on scm:status goal. Running package lifecycle the plugin doesn't even show up in the standard output. <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-scm-plugin</artifactId> <version>1.5</version> <configuration> <connectionType>connection</connectionType> <excludes>target</excludes> </configuration> </plugin> Is there more concise documentation on how the Maven SCM plugin and providers interact. I'm able to get the source for the plugin but can't find a URL for the source code for the Clear Case provider.
        Hide
        Robert Scholte added a comment -

        To fix this we need to borrow a ScmUrlParserResult which is used by some providers, for instance the AbstractSvnScmProvider.

        Show
        Robert Scholte added a comment - http://maven.apache.org/scm/index.html for general scm info http://maven.apache.org/scm/clearcase.html for clearcase info http://maven.apache.org/scm/source-repository.html for the sources. https://svn.apache.org/repos/asf/maven/scm/trunk/ points to the current trunk To fix this we need to borrow a ScmUrlParserResult which is used by some providers, for instance the AbstractSvnScmProvider .
        Hide
        Justin Bleach added a comment - - edited

        Looking at the source:

        Is not the ClearCaseScmProviderRepository.java instantiated with with full URL? (scm|clearcase|c:\views\tempview\configSpec.txt). If that happens you don't have to worry about putting in the last pipe as the first pipe after "scm" should do.

        When I debug to the "fillDefaultProperties" private method in the class I mentioned above it appears I have 3 tokens. In this method it assumes if only one token is available there is no view defined (which I don't have defined). I don't have a view defined but I have 3 tokens.

        I looked at the SCM API as well. Am I missing where the SCM and clearcase part is stripped off before ClearCaseScmProviderRepository is instantiated? It would make sense they aren't part of the URL since they are basically telling the API which provider to use but I can't find where that happens.

        Show
        Justin Bleach added a comment - - edited Looking at the source: Is not the ClearCaseScmProviderRepository.java instantiated with with full URL? (scm|clearcase|c:\views\tempview\configSpec.txt). If that happens you don't have to worry about putting in the last pipe as the first pipe after "scm" should do. When I debug to the "fillDefaultProperties" private method in the class I mentioned above it appears I have 3 tokens. In this method it assumes if only one token is available there is no view defined (which I don't have defined). I don't have a view defined but I have 3 tokens. I looked at the SCM API as well. Am I missing where the SCM and clearcase part is stripped off before ClearCaseScmProviderRepository is instantiated? It would make sense they aren't part of the URL since they are basically telling the API which provider to use but I can't find where that happens.
        Hide
        Robert Scholte added a comment -

        https://svn.apache.org/repos/asf/maven/scm/trunk/maven-scm-api/src/main/java/org/apache/maven/scm/manager/AbstractScmManager.java
        In the public ScmRepository makeScmRepository( String scmUrl ) the URL is split up.
        First part must be scm, second part picks up the right provider, third part is passed as the scmSpecificUrl

        Show
        Robert Scholte added a comment - https://svn.apache.org/repos/asf/maven/scm/trunk/maven-scm-api/src/main/java/org/apache/maven/scm/manager/AbstractScmManager.java In the public ScmRepository makeScmRepository( String scmUrl ) the URL is split up. First part must be scm, second part picks up the right provider, third part is passed as the scmSpecificUrl
        Hide
        Justin Bleach added a comment -

        I was able to work around the issue by doing this (includes the view now as well):
        <connection>scm|clearcase|my_view|file:///c://views//my_view//configSpec.txt</connection>

        Robert as you mentioned ScmUrlParserResult which is a private class in AbstractSvnScmProvider should basically be copied for the Clear Case provider. This way when the Clear Case provider attempts to make a URL from "c:\views\..." it doesn't barf and instead adds the "file://" to the URL to make it valid, else perhaps this could be communicated in documentation as "a feature" (parameter must be valid URL).

        Let me know, if I have time this weekend I may look into trying to fix this and check it in (whatever all is involved in that, not contributed to open source project before). I can look at it when no view is specified as well.

        Show
        Justin Bleach added a comment - I was able to work around the issue by doing this (includes the view now as well): <connection>scm|clearcase|my_view|file:///c://views//my_view//configSpec.txt</connection> Robert as you mentioned ScmUrlParserResult which is a private class in AbstractSvnScmProvider should basically be copied for the Clear Case provider. This way when the Clear Case provider attempts to make a URL from "c:\views\..." it doesn't barf and instead adds the "file://" to the URL to make it valid, else perhaps this could be communicated in documentation as "a feature" (parameter must be valid URL). Let me know, if I have time this weekend I may look into trying to fix this and check it in (whatever all is involved in that, not contributed to open source project before). I can look at it when no view is specified as well.
        Hide
        Robert Scholte added a comment -

        There are other ScmProviders which use their own private ScmUrlParserResult class, whcih can help you to write it for the ClearCase provider.
        If you've checked out the code from trunk, you can apply my patch. That test will now fail, but should succeed once the ScmUrlParserResult has been properly developed.
        If you're ready, just create a patch from you modifications and upload it here, so we can have a look at it.

        Show
        Robert Scholte added a comment - There are other ScmProviders which use their own private ScmUrlParserResult class, whcih can help you to write it for the ClearCase provider. If you've checked out the code from trunk, you can apply my patch. That test will now fail, but should succeed once the ScmUrlParserResult has been properly developed. If you're ready, just create a patch from you modifications and upload it here, so we can have a look at it.
        Hide
        Michael Osipov added a comment -

        Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.

        Show
        Michael Osipov added a comment - Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.

          People

          • Assignee:
            Unassigned
            Reporter:
            Justin Bleach
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: