The perforce provider should be able to accept complex filespecs using a clientspec rather than the path in the SCM url

One of the strengths of perforce is the ability to do fairly complex actions with the clientspec.

For example:

1 - Checkout two file structures into one location:
//depot1/tree1/... //client/project/tree1
//depot2/tree2/... //client/project/tree2

2 - Rename file structures at checkout time :
//depot/tree/sample-configuration.xml //client/tree/configuration.xml

The SCM URL format doesn't allow this (and implementing it would be difficult)

Currently, the perforce provider doesn't seem to allow a way to use an existing clientspec (all codepaths seem to create a new clientspec based on the URL)

If the provider could allow an existing clientspec to define the file structure, this functionality could be enabled.

Testing:

I don't have any JUnit experience, but I think this could be tested by:

1 - Create a clientspec that defines some complex content, for example:
//depot/project/src/... //clientspec/project/src/...
//ThirdParty/... //clientspec/project/ThirdParty/...

2 - run "mvn scm:checkout" and all files should be checked out.

Implementation Ideas:

I can see multiple ways of doing this, depending on the restrictions/conventions required

A - Use the existing "bootstrap/target/checkout" dynamic directory structure

• Using "p4 client -o" with the given/predefined/assumed clientspec, alter the p4_root (the line containing "Root:") and do a "p4 sync -f"
  (Definition of the clientspec ideas defined separately below)

B - Assume the clientspec has a defined "Root:" and use that for the purposes of "locating" files (needed for tag/editing/checkin purposes)

• As I'm only checking out, I really don't know how this would affect a checkin

C - Separate from above, how to define which clientspec to use:

• In the SCM URL, perhaps with scm:perforce:[username@]host:port:@clientspec_name
  (the second @ being a placeholder for a delimiter)
• As an environment variable (perhaps the existing maven.scm.perforce.clientspec.name,
  enabling this functionality (re-use vs. re-create) with a different property
• Defined in the settings.xml or in the pom.xml in the SCM configuration properties

I'm sure more details will be required, this is only what I've identified within my particular situation.