Depends On, vs child, and how to deal with related defects
We are in production using RTC 3.0 iFix 1. we are starting to migrate from other systems to RTC for defect management.. but we have two problems..
1. Depends On link type does NOT block the upstream workitem from closing for the 'depended on' is still open.. We opened a defect and got 'working as designed' .. How can a Depends On, NOT BLOCK the close action? enhancement 182769 was opened, but I think this is a defect.
depends on without blocking is the same as 'mentioned', barely useful.
2. we receive a defect, work it, fix it, ship the fix, close it.
some time later (beyond our reopen policy, 90 days) we receive a new defect, which is in fact caused by the first. We need to link the two workitems together reliably so that when we build the fixes, this new one can reference the old one as a pre-req.
but.. because the original is closed, we cannot make the old workitem a parent of the new,
and we cannot update the original workitem to make the new workitem a child because the old workitem is closed.
We are not allowed to reopen the old workitem.
using mentions is too weak, and there may be multiple reasons to have mentions, which may not lead to a pre-req fix chain..
anyone have any clues how to resolve these two issues?
Sam
1. Depends On link type does NOT block the upstream workitem from closing for the 'depended on' is still open.. We opened a defect and got 'working as designed' .. How can a Depends On, NOT BLOCK the close action? enhancement 182769 was opened, but I think this is a defect.
depends on without blocking is the same as 'mentioned', barely useful.
2. we receive a defect, work it, fix it, ship the fix, close it.
some time later (beyond our reopen policy, 90 days) we receive a new defect, which is in fact caused by the first. We need to link the two workitems together reliably so that when we build the fixes, this new one can reference the old one as a pre-req.
but.. because the original is closed, we cannot make the old workitem a parent of the new,
and we cannot update the original workitem to make the new workitem a child because the old workitem is closed.
We are not allowed to reopen the old workitem.
using mentions is too weak, and there may be multiple reasons to have mentions, which may not lead to a pre-req fix chain..
anyone have any clues how to resolve these two issues?
Sam
9 answers
Hi Sam,
as far as I know there was never any semantic behind the blocking work item dependency, it was purely informational. So it works as designed. However, you could desire more and the enhancement request is fine. If you don't want to wait until it is done you could create an extension - an adviser - which is an eclipse plug-in on the server. This could block changing to a saved state in case there is a dependency to another blocking work item. https://jazz.net/library/article/477 talks about how to do this kind of extensions. https://jazz.net/wiki/bin/view/Main/RtcSdk30 covers the API, examples and additional information.
You would create a precondition that validates the condition.
I don't understand the second part of the question. You should reopen the defect if it is causing the issue. It was not really fixed otherwise it would have no influence. If you have rules not to do that, you could duplicate the work item. However it sounds like the real problem seem to be the rules of your chosen process and not the tool.
as far as I know there was never any semantic behind the blocking work item dependency, it was purely informational. So it works as designed. However, you could desire more and the enhancement request is fine. If you don't want to wait until it is done you could create an extension - an adviser - which is an eclipse plug-in on the server. This could block changing to a saved state in case there is a dependency to another blocking work item. https://jazz.net/library/article/477 talks about how to do this kind of extensions. https://jazz.net/wiki/bin/view/Main/RtcSdk30 covers the API, examples and additional information.
You would create a precondition that validates the condition.
I don't understand the second part of the question. You should reopen the defect if it is causing the issue. It was not really fixed otherwise it would have no influence. If you have rules not to do that, you could duplicate the work item. However it sounds like the real problem seem to be the rules of your chosen process and not the tool.
thanks for the response..
on the first.. extension.. ouch.. but I'll look at it..
on the second.. I cannot reopen the defect, I cannot change the deliverable.
Our policy sets 90 days as the window...
now I need to tool to support the business policy.. but I haven't figured out how.. and am looking for guidance.. I'm not in charge of the policy.. only the tools..
Sam
on the first.. extension.. ouch.. but I'll look at it..
on the second.. I cannot reopen the defect, I cannot change the deliverable.
Our policy sets 90 days as the window...
now I need to tool to support the business policy.. but I haven't figured out how.. and am looking for guidance.. I'm not in charge of the policy.. only the tools..
Sam
a little nudge.. I used the example, and created the save operation advisor to check for 'depends on' links, and follow those..
but I don't see it on the client to configure as part of the operation Save pre-conditions.
the workshow shows a big complex 5 part server/client side interprocess communications setup ..
I don't understand the model, and the sample isn't the 5 part thing..
(i've previously built a server side service accessed by client side code, so I've done that)..
but I don't think this should be more than a server side plugin.. just can't get it configured and it doesn't fire..
Sam
but I don't see it on the client to configure as part of the operation Save pre-conditions.
the workshow shows a big complex 5 part server/client side interprocess communications setup ..
I don't understand the model, and the sample isn't the 5 part thing..
(i've previously built a server side service accessed by client side code, so I've done that)..
but I don't think this should be more than a server side plugin.. just can't get it configured and it doesn't fire..
Sam
Hi Sam,
I would consider to use the Extensions workshop debug set up to test the extension. You should see it if you follow the labs in the operational behavior process configuration (Team Configuration). The example is a post condition. I know the labs by heart and if you followed them you would see the post condition.
See https://jazz.net/wiki/bin/view/Main/RtcSdk30 for the SDK. There are examples. there are other examples in the library and on developer works.
See https://jazz.net/wiki/bin/view/Main/RTCSDK20_ProcessPreConditionExample for a precondition.
Finally, after you are sure your extension works the last lab of the Extension workshop (NOT the OSLC workshop) shows how to package and deploy on your production server.
Unfortunately it is almost impossible to remote control this using the forums 8-). you have to go through the pain 8-) The Extending RTC forum is where these things are being discussed.
I would consider to use the Extensions workshop debug set up to test the extension. You should see it if you follow the labs in the operational behavior process configuration (Team Configuration). The example is a post condition. I know the labs by heart and if you followed them you would see the post condition.
See https://jazz.net/wiki/bin/view/Main/RtcSdk30 for the SDK. There are examples. there are other examples in the library and on developer works.
See https://jazz.net/wiki/bin/view/Main/RTCSDK20_ProcessPreConditionExample for a precondition.
Finally, after you are sure your extension works the last lab of the Extension workshop (NOT the OSLC workshop) shows how to package and deploy on your production server.
Unfortunately it is almost impossible to remote control this using the forums 8-). you have to go through the pain 8-) The Extending RTC forum is where these things are being discussed.
thanks.. I got the packaging and deploying part as I have other server plugins..
the issue is the precondition doesn't appear in the project config, team config, operation data section, when I select workitem Save as the operation to configure..
the code is simple enough
this is configured as a plugin on ccm, not jts. (as the dependant com.ibm.team.workitem.common is not available in the jts app).
the plugin.xml is easy too
I don't see any loading errors in the log (I do if I try to load this in JTS)
I don't have an activator class, so maybe I'll add one just to see the startup/shutdown message.. but I am using the example code, so this should not be the problem.
from my eclipse, I open the plugin view, and my plugin is in the list.
so that means it was loaded, and not failed.
this was the nudge part.. something tiny, but obvious to others..
Sam
the issue is the precondition doesn't appear in the project config, team config, operation data section, when I select workitem Save as the operation to configure..
the code is simple enough
/*******************************************************************************
* Licensed Materials - Property of IBM (c) Copyright IBM Corporation 2005-2006.
* All Rights Reserved.
*
* Note to U.S. Government Users Restricted Rights: Use, duplication or
* disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
******************************************************************************/
package advisor.example;
import java.util.List;
import org.eclipse.core.runtime.IProgressMonitor;
import com.ibm.team.links.common.registry.IEndPointDescriptor;
import com.ibm.team.links.common.registry.ILinkType;
import com.ibm.team.process.common.IProcessConfigurationElement;
import com.ibm.team.process.common.advice.AdvisableOperation;
import com.ibm.team.process.common.advice.IAdvisorInfo;
import com.ibm.team.process.common.advice.IAdvisorInfoCollector;
import com.ibm.team.process.common.advice.runtime.IOperationAdvisor;
import com.ibm.team.repository.common.TeamRepositoryException;
import com.ibm.team.workitem.common.ISaveParameter;
import com.ibm.team.workitem.common.model.IWorkItemReferences;
public class WorkItemFailAdvisor implements IOperationAdvisor {
public void run(AdvisableOperation operation, IProcessConfigurationElement advisorConfiguration, IAdvisorInfoCollector collector, IProgressMonitor monitor) throws TeamRepositoryException {
System.out.println("in operation advisor");
Object data= operation.getOperationData();
if (data instanceof ISaveParameter) {
IWorkItemReferences iwr = ((ISaveParameter) data).getNewReferences();
List<IEndPointDescriptor> epdl = iwr.getTypes();
for(int i=0;i<epdl.size();i++)
{
ILinkType lt = epdl.get(i).getLinkType();
System.out.println("link type = "+ lt.getLinkTypeId()+ " name="+epdl.get(i).getDisplayName());
if(lt.getLinkTypeId().contains("Depends"))
{
IAdvisorInfo info = collector.createProblemInfo("Dependency not resolved", "The Dependent Workitem is not closed", "error");
collector.addInfo(info);
}
}
}
}
}
this is configured as a plugin on ccm, not jts. (as the dependant com.ibm.team.workitem.common is not available in the jts app).
the plugin.xml is easy too
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.4"?>
<plugin>
<extension
point="com.ibm.team.process.service.operationAdvisors">
<operationAdvisor
class="advisor.example.WorkItemFailAdvisor"
id="advisor.example.operationAdvisor"
name="Restrict &apos;fail&apos; in summary"
operationId="com.ibm.team.workitem.operation.workItemSave">
</operationAdvisor>
</extension>
</plugin>
I don't see any loading errors in the log (I do if I try to load this in JTS)
I don't have an activator class, so maybe I'll add one just to see the startup/shutdown message.. but I am using the example code, so this should not be the problem.
from my eclipse, I open the plugin view, and my plugin is in the list.
so that means it was loaded, and not failed.
this was the nudge part.. something tiny, but obvious to others..
Sam
I added an Activator class
and see it advise on the server console
Nov 4, 2011 8:56:16 AM org.apache.catalina.startup.Catalina star
INFO: Server startup in 12379 ms
advisor started
still doesn't show in the precondition list on the client.
this is an existing project opened on the client..
I logged off/on, did a refresh.. no change
it does not appear in the list for a newly created project either.
this is 3.0 iFix 1.
we are planning upgrade to 3.0.1(.1) soon
just for clarity, I am following this guide https://jazz.net/library/article/495
at Enable and Test Plug-in, step 5.. the advisor does not appear in the list.
Sam
and see it advise on the server console
Nov 4, 2011 8:56:16 AM org.apache.catalina.startup.Catalina star
INFO: Server startup in 12379 ms
still doesn't show in the precondition list on the client.
this is an existing project opened on the client..
I logged off/on, did a refresh.. no change
it does not appear in the list for a newly created project either.
this is 3.0 iFix 1.
we are planning upgrade to 3.0.1(.1) soon
just for clarity, I am following this guide https://jazz.net/library/article/495
at Enable and Test Plug-in, step 5.. the advisor does not appear in the list.
Sam
If everything is OK you should see the advisor when you enable the preconditon section.
I have examples that ran with 2.0 and despite some minimal changes this setup: https://jazz.net/library/article/477 works probably well for 2.x as well.
You might be missing some dependenxies or the plugin.xml is not correct. Hard to tell. The Extending Team concert forum is the one to discuss this.
I have examples that ran with 2.0 and despite some minimal changes this setup: https://jazz.net/library/article/477 works probably well for 2.x as well.
You might be missing some dependenxies or the plugin.xml is not correct. Hard to tell. The Extending Team concert forum is the one to discuss this.
If everything is OK you should see the advisor when you enable the preconditon section.
I have examples that ran with 2.0 and despite some minimal changes this setup: https://jazz.net/library/article/477 works probably well for 2.x as well.
You might be missing some dependencies or the plugin.xml is not correct. Hard to tell. The Extending Team concert forum is the one to discuss this.
thanks..
this topic in Extending..
https://jazz.net/forums/viewtopic.php?t=20488
I usually see dependancy failures in the log when they are wrong or missing. I am using the sample, which I 'assume' (I know) are correct.
sam
I can't debug it with just that information. Check the build part in the plugin definition and make sure to export the plugin.xml as well as all other required files. Use the Extensions workshop to debug. If it runs in a dev environment fixing the build.xml usually does the trick. Also the extension worshop says you have to add the prerequisites to the plugin XML. This is clearly missing in your example and your plugin will never work, even if it showed up. Which you would catch during debug as well.
See the code below
Important you need to declare the services you use as described in the workshop. for example:
See the code below
<xml>
<eclipse>
<plugin>
<extension>
<operationParticipant>
<extensionService>
<prerequisites>
<requiredService>
<requiredService>
<requiredService>
</prerequisites>
</extensionService>
<description>
When the specified work item type changes to the specified state, the specified build will be requested.
</description>
</operationParticipant>
</extension>
</plugin>
Important you need to declare the services you use as described in the workshop. for example:
<prerequisites>
<requiredService>
<requiredService>
<requiredService>
</prerequisites>