Maven SCM

Replace DEFAULT_CLIENTSPEC_PROPERTY system property by a map to store in memory clientspec names

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Critical Critical
  • Resolution: Unresolved
  • Affects Version/s: 1.0-beta-4
  • Fix Version/s: 1.x
  • Component/s: maven-scm-provider-perforce
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

With a Map instead of a system property, we'll can support more that one clientspec in the jvm. It's necessary for Continuum because it access to more than one project in Perforce.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Mike Perham added a comment -

E, I'm on vacation for the next week.

Show
Mike Perham added a comment - E, I'm on vacation for the next week.
Hide
Permalink
Mike Perham added a comment -

Patrick, do you have any time to work on this?

Show
Mike Perham added a comment - Patrick, do you have any time to work on this?
Hide
Permalink
Mike Perham added a comment -

E, can you give more details about how you expect this to work? Am I supposed to map

{ directory -> clientspec-name }

? The SCM provider really only knows the current directory it is working with. So how will Continuum pass me the clientspec name to use?

Show
Mike Perham added a comment - E, can you give more details about how you expect this to work? Am I supposed to map { directory -> clientspec-name } ? The SCM provider really only knows the current directory it is working with. So how will Continuum pass me the clientspec name to use?
Hide
Permalink
Emmanuel Venisse added a comment -

Continuum know only the scm url.and the working directory.
The actual DEFAULT_CLIENTSPEC_PROPERTY system property can't be used because in a CI tool like continuum, we manage more that one project so more than one clientspec, and this system property allow only one.

I thought to a map that will contain all client specs with the scm url in the key and the client spec in the value.
Do you think it can work? The client spec is generated at the end of the checkout, right?

Show
Emmanuel Venisse added a comment - Continuum know only the scm url.and the working directory. The actual DEFAULT_CLIENTSPEC_PROPERTY system property can't be used because in a CI tool like continuum, we manage more that one project so more than one clientspec, and this system property allow only one. I thought to a map that will contain all client specs with the scm url in the key and the client spec in the value. Do you think it can work? The client spec is generated at the end of the checkout, right?
Hide
Permalink
Patrick Schneider added a comment -

I am pretty busy, but I can take a look.

Show
Patrick Schneider added a comment - I am pretty busy, but I can take a look.
Hide
Permalink
Mike Perham added a comment -

But where does this map come from? Who creates it? No, the clientspec is completely independent from the checkout and in most cases is not created by the provider.

Show
Mike Perham added a comment - But where does this map come from? Who creates it? No, the clientspec is completely independent from the checkout and in most cases is not created by the provider.
Hide
Permalink
Mike Perham added a comment -

I might be able to get the existing clientspec name using 'p4 where pom.xml' and examining the output but this doesn't help in the case where I want to checkout a new project using an existing clientspec. Let me think about this more.

Show
Mike Perham added a comment - I might be able to get the existing clientspec name using 'p4 where pom.xml' and examining the output but this doesn't help in the case where I want to checkout a new project using an existing clientspec. Let me think about this more.
Hide
Permalink
Mike Perham added a comment -

I don't see any way to support multiple clientspecs without explicit support in Continuum and SCM. We need support for ad hoc variables associated with a build which can be passed to the provider. The system property is a hack which obviously doesn't scale.

Show
Mike Perham added a comment - I don't see any way to support multiple clientspecs without explicit support in Continuum and SCM. We need support for ad hoc variables associated with a build which can be passed to the provider. The system property is a hack which obviously doesn't scale.
Hide
Permalink
Emmanuel Venisse added a comment -

Possible solution without modification in continuum:

instead of system property, we can store the clientspec in $

{user.home}

/.scm/perforce.xml (other providers use a xml file to configure the provider too)
In this file we store a mapping between the scmurl and the clientspec

<settings>
    <clientSpecMappings>
        <clientSpecMapping>
            <scmUrl>scm:perforce:username@host:port:path_to_repository1</scmUrl>
            <clientSpecName>username-host-MavenSCM-path-to-repo1</clientSpecName>
        </clientSpecMapping>
        <clientSpecMapping>
            <scmUrl>scm:perforce:username@host:port:path_to_repository2</scmUrl>
            <clientSpecName>username-host-MavenSCM-path-to-repo2</clientSpecName>
        </clientSpecMapping>
    </clientSpecMappings>
</settings>

and in PerforceScmProvider.getClientspecName(...) we return the clientSpecName from the xml file. If if doesn't exist, we generate a default name and we store it in the xml file.

WDYT?

Show
Emmanuel Venisse added a comment - Possible solution without modification in continuum: instead of system property, we can store the clientspec in $ {user.home} /.scm/perforce.xml (other providers use a xml file to configure the provider too) In this file we store a mapping between the scmurl and the clientspec <settings> <clientSpecMappings> <clientSpecMapping> <scmUrl>scm:perforce:username@host:port:path_to_repository1</scmUrl> <clientSpecName>username-host-MavenSCM-path-to-repo1</clientSpecName> </clientSpecMapping> <clientSpecMapping> <scmUrl>scm:perforce:username@host:port:path_to_repository2</scmUrl> <clientSpecName>username-host-MavenSCM-path-to-repo2</clientSpecName> </clientSpecMapping> </clientSpecMappings> </settings> and in PerforceScmProvider.getClientspecName(...) we return the clientSpecName from the xml file. If if doesn't exist, we generate a default name and we store it in the xml file. WDYT?
Hide
Permalink
Emmanuel Venisse added a comment -

Mike, ping.

Show
Emmanuel Venisse added a comment - Mike, ping.
Hide
Permalink
Raphael PETIT added a comment -

Currently, each client spec has

  • a root with the unique number at the end
  • a view defined by one line

Maybe, it can be changed to a unique client spec

  • a root (global definition)
  • a view defined by several line the unique number at the end

So things seems to be manageable without continnum concept in the scm...

Show
Raphael PETIT added a comment - Currently, each client spec has a root with the unique number at the end a view defined by one line Maybe, it can be changed to a unique client spec a root (global definition) a view defined by several line the unique number at the end So things seems to be manageable without continnum concept in the scm...

People

  • Assignee:
    Patrick Schneider
    Reporter:
    Emmanuel Venisse
Vote (2)
Watch (3)

Dates

  • Created:
    Updated: