ImmutablePropertyException on file
N. VD (84●27●34)
| asked Feb 05 '15, 10:51 a.m.
retagged Feb 05 '15, 11:24 a.m. by Evan Hughes (2.4k●13●18)
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)
|
One answer
Evan Hughes (2.4k●13●18)
| answered Feb 05 '15, 11:23 a.m.
JAZZ DEVELOPER edited Feb 05 '15, 11:24 a.m.
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:
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
):
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 1
N. VD
commented Feb 05 '15, 3:21 p.m.
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.
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.
N. VD
commented Feb 05 '15, 4:52 p.m.
Evan, thanks for the clear explanation.
Thanks for the tip about follow-up actionsm i'll look into that.
N. VD
commented Feb 06 '15, 9:20 a.m.
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.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.