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

Maven SCM

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

Created: 28/Nov/06 07:02 PM Updated: 18/May/08 04:19 PM

Component/s:

maven-scm-provider-perforce

Affects Version/s:

None

Fix Version/s:

future

Time Tracking:

Not Specified

Environment:

All OS, Maven 2.x using the SCM plugin to talk to perforce

Complexity:

Intermediate

Description

« Hide

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.

Description

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.

Show »

All

Comments

Work Log

Change History

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Mike Perham - 02/Dec/06 01:27 AM

Dana, I don't believe the Perforce provider will ever provide easy, ad hoc SCM operations. The semantics are just too far removed from what CVS/SVN provide (and the SCM API assumes).

You should be able to set up a clientspec by hand and then use 'mvn -Dmaven.scm.perforce.clientspec.name=<clientspec-name> scm:checkout' to check out the contents of that clientspec to the current directory. Note the checkout command will update the clientspec to change the Root to the current directory.

See ~~SCM-110~~ for details on force syncing.

If this is sufficient for your needs, please let me know so I can close this issue.

[ Permlink | « Hide ]

Mike Perham - 02/Dec/06 01:38 AM

mvn -Dmaven.persist.checkout=true -Dmaven.scm.perforce.clientspec.name=<clientspec-name> scm:checkout

This will sync the contents of that clientspec to the current directory. If the current directory is empty, it will force sync. The persistcheckout flag ensures that the command will not delete the clientspec when the command is complete (as it does by default). Note this command is exactly the same as your other issue with update.

[ Permlink | « Hide ]

Dana Lacoste - 06/Dec/06 02:56 PM

Unfortunately, the same problem as in the other issue occurs:

update and checkout are the same, and they both (in the first try {} block of executeCheckoutCommand()) overwrite the existing clientspec with the fileset information provided in the SCM URL....

[ Permlink | « Hide ]

Matthias Wurm - 09/Dec/06 05:15 AM

Actually, the property to make the dynamically created clientspec persistent is maven.scm.persistcheckout

[ Permlink | « Hide ]

Grzeg Plotnicki - 25/Jun/07 12:07 PM - edited

The ability to provide a complex filespec using perforce's own clientspec rather than the minimal path in the scm url seems like a FUNDAMENTAL issue to be resolved in order for the maven perforce plug-in to be useable. (please, correct me if I'm wrong!!!

) this inability is made worst by the fact that the current implementation of the maven perforce plug-in will actually overwrite the existing clientspec making it unusable as well.

Considering that it's been over 6 months since the issue has been reported and it's still not fixed, the question is really: is my understanding of what is fundamental to the functioning of maven perforce plug-in incorrect or is the development of the plug-in stagnated?

p.s.
please, excuse (and redirect) if this is not the right forum to ask this question.

[ Permlink | « Hide ]

Brian Jackson - 19/Jul/07 11:58 AM

I'm now also running into the problem that the plugin overwrites the existing clientspec (seemingly during release only?) If I set maven.scm.persistcheckout, will that prevent it from overwriting the existing clientspec?

[ Permlink | « Hide ]

Dana Lacoste - 19/Jul/07 12:27 PM

I haven't investigated the code since November 2006, but at that time, Brian, but at that time this would happen :

1 - read filespec line
2 - create new clientspec with filespec line as referenced (over-write, not append)
3 - sync
4 - if not persist, delete clientspec. if persist, keep clientspec.

so you always lost your current clientspec, though you could keep it for manual work later.

It's just the way the code was written. the persist variable was not investigated at clientspec create, only at clientspec delete.

[ Permlink | « Hide ]

Harold Shinsato - 18/May/08 04:19 PM

Is there any way to make the perforce plugin work with the release plugin if you don't have a one directory clientspec? I'm quite confused. The release:prepare task seems to be blocked but it's unclear if this is the issue - but it looks like it might be because of the message that "+//myspec" doesn't match "//myspec", the release:prepare task reports.

[INFO] The SCM location in your pom.xml (//myspec) is not equal to the depot location (+//myspec). This happens frequently with branches. Ignoring the SCM location.