Welcome to the Jazz Community Forum
ImmutablePropertyException on file
Forum,
When i try to change an IFileItem, i get the ImmutablePropertyException.
I have found some posts on the forum to work with a workingcopy of the file, so i did.
but the change i make to the workingcopy does not get applied into the stream...
(i'm extending the delivery process)
fileItemCopy.setUserProperty(PROPERTY, definition_UUID); // change not applied in the stream
fileItem.setUserProperty(PROPERTY, definition_UUID); // throws ImmutablePropertyException
One answer
Are you dealing with an
IWorkspace
that the user has loaded into a sandbox, or are you manipulating a repository workspace by fiddling with the server?
If you're working with a loaded repository workspace that has been loaded into the sandbox, you should make your changes locally by:
- getting an IShareable for the file you care about,
- grabbing the user properties from the shareable with getMetadataProperties() ,
- modify the properties,
- run IOperationFactory.instance.getChangePropertiesOperation() to get an object that's capable of saving your modifications
- use IChangePropertiesOperation#setProperties() followed by run() to update the local metadata
On the other hand, if you're directly manipulating an unloaded repository workspace, you can create a change set to record your changes directly. To do that using the client libraries (ie, an
IWorkspaceConnection
):
- Modify the IFileItem working copy as you're doing today,
- call wsConn.configurationOpFactory() on your workspace connection to get the op factory,
- call factory.save(fileItemCopy) to create the save operation that you want to commit,
- call wsConn.commit() on the save operation from the previous step.
You can commit with the server APIs by calling
IScmService
directly, which is roughly analogous to using the client libraries. The difference being that you call
IScmService#batchCommit()
to commit.
Comments
Evan,
thanks for putting the effort in answering the question in such a clear way.
Does this also apply for a server-side advisor?
I'm using a delivery advisor to change a specific userproperty on this file directly in the changeset that is getting deliverd into the stream.
1 vote
I'm using a delivery advisor to change a specific userproperty on this file directly in the changeset that is getting deliverd into the stream.
I don't recommend modifying change sets while the advisor is running, since advisors aren't supposed to modify their arguments. Additionally, the change sets that are being delivered may be closed, so your changes may end up creating a new change set that isn't one of the delivery arguments. I'm not sure what will happen in that scenario. :)
(Okay, I have an idea of what will happen: exceptions)
Have you looked at follow-up actions? I believe they are intended to allow modifications to data. I don't have a lot of experience with them, so I can't say whether or not there are gotchas you'll have to worry about.
Evan, thanks for the clear explanation.
Thanks for the tip about follow-up actionsm i'll look into that.
IScmService#batchCommit(), as u stated gives me this error:
Illegal operation ('commit') for stream 'MyLifecycleProject (Change Management) Stream'
I only have the target workspace available in my delta. (and that's the stream i suppose)
Sorry - that completely slipped my mind: change sets can't be created or committed to on a stream (that's an IWorkspace with the 'stream' bit set). Instead you need to create the change sets on another workspace and deliver them.
The usual pattern for working with process in RTC is that you create an advisor that enforces some constraint (such as requiring a specific property) and prevents users from delivering to a stream unless that constraint is met. Then you provide client-side tooling that makes it easy for the user to make the appropriate changes. For example, the Eclipse UI provides a bunch of quick fixes for process failures in the Team Advisor view.