The following issues are known to exist in CollabNet
Tracker Connector for HP Quality Center
4.0
.
- Conflicts in artifact data are not handled
- If two mapped artifacts are changed at the same time, the connector picks up the one for
the tracker which gets its turn first, and overwrites the data on the target artifact.
- Dependencies and associations are not shipped
- In SourceForge, it is possible to relate artifacts to each other in a parent-child
relationship or some other kind of dependency. Artifacts may also be associated with other
entities that are not tracker items. These dependencies and associations are not shipped
along with the artifact data.
- Deletion of artifacts is not supported
- If a SourceForge tracker artifact is deleted, the deletion event is not shipped to
Quality Center. Similarly if a Quality Center defect is deleted, the event is not shipped
to SourceForge. So the target defect or artifact that was mapped to the source item is not
deleted. Users are required to manually delete the defect or artifact on the target
system.
- GUI configuration and mapping tools are not available
- There is no graphical user interface to set up the tracker and field transformation
mappings. Users are expected to be familiar with XSLT and the configuration files to set
up the mappings. There are, however, several sample XSLT files available in the different
scenarios provided with this product, and can be used as templates for further
customizations.
- Attachment links shipped from Quality Center to SourceForge are wrapped in a file
- Quality Center has the ability to store attachments as links, but SourceForge does not
have that capability. When a link attachment is transported from Quality Center to
SourceForge, the SourceForge plugin wraps the link in a file and attaches it to the target
SourceForge artifact.
- Limitations with shipment of artifacts that fail
- If an artifact shipment fails, other available source artifacts get shipped to the
target repository. Until there is some change in the source artifact that failed, it does
not get shipped to the target. If an artifact fails during shipment, and there are no
other artifacts available, the CCF keeps trying to ship the failing artifact. It stops
only when there is some other artifact that gets successfully shipped to the target.
- HTML snippets in description field are shipped as encoded string from SourceForge to
Quality Center
- Using the Quality Center web interface, the description of a defect can be formatted
with bold, italics and various other characteristics. But formatting text through
OTAClient, the component used by this connector framework for communication with Quality
Center, renders the HTML formatting to be displayed as entity references. For example,
<b> is rendered as <b> See http://ccf-qc.open.collab.net/servlets/tracking/id/ccf122 for details.
- Systems are constantly polled
- The connector keeps on polling the configured systems, SourceForge and Quality Center,
for changed artifact data. The default poll interval is set to 1 second to avoid chances
of the mapped artifacts getting into a delta conflict. Due to the low polling interval,
network traffic might be considerable. To control network traffic, it is recommended that
users increase the polling interval as required, while ensuring that artifacts are not
modified simultaneously on both ends within that short interval.
- During mass updates, the SourceForge SOAP API skips some artifacts
- If the CCF polls a SourceForge tracker for changed artifacts during a mass update
operation of that tracker's artifacts, the SourceForge SOAP API has been observed to skip
some of the changed artifacts that are eligible for shipment. See http://ccf.open.collab.net/servlets/tracking?id=ccf36 for details.
- Shipping of huge attachments is limited
- Shipment of huge attachments is limited by the memory available on the machine where the
CCF runs. You need to restrict the maximum attachment size in accordance with the Java
Virtual Machine memory.