The open source projects have moved to a new server.
In particular, the new URL for the CMVC-RTC project is:
https://csnext.ibm.com/TrioWeb/viewProjectDetails.do?projectID=16952

According to the info there, 2-way synchronization is still a future
feature.

Cheers,
Geoff

On 7/12/2011 2:23 PM, bweech wrote:

yzwkzfnwrote:


Short answer: The two-way synchronization is not yet provided.

See the forum on this Open Source project

https://cs.opensource.ibm.com/forum/?group_id=3622

So has anything changed regarding two-way synchronization since
November? Specifically, I'm looking to sync between RTC and GForge.

Also, I can't connect to https://cs.opensource.ibm.com. Did the server
move or is it down?

Short answer: The two-way synchronization is not yet provided.

See the forum on this Open Source project

https://cs.opensource.ibm.com/forum/?group_id=3622

So has anything changed regarding two-way synchronization since November? Specifically, I'm looking to sync between RTC and GForge.

Also, I can't connect to https://cs.opensource.ibm.com Did the server move or is it down?

How does one control the synchronisation of defects between CMVC and RTC?
I have successfully imported Defects from CMVC into RTC using the CmvcWorkizemConector.jar but cannot maintain a pemanent synchronisation between them. Changes to a defect in CMVC sometimes permeate through to RTC but changes in RTC are never reflected in CMVC.

Has anyone successfully achieved this? If so perhaps you can pass on a few tips. I am sure there is something basic that I have missed.

Short answer: The two-way synchronization is not yet provided.

See the forum on this Open Source project

https://cs.opensource.ibm.com/forum/?group_id=3622

How does one control the synchronisation of defects between CMVC and RTC?
I have successfully imported Defects from CMVC into RTC using the CmvcWorkizemConector.jar but cannot maintain a pemanent synchronisation between them. Changes to a defect in CMVC sometimes permeate through to RTC but changes in RTC are never reflected in CMVC.

Has anyone successfully achieved this? If so perhaps you can pass on a few tips. I am sure there is something basic that I have missed.

One followup point:

An "importer" is a special kind of synchronizer, namely, a one-way
synchronizer. Jazz provides several importers, primarily for importing
work items (e.g., from Bugzilla) or importing SCM change-sets and
streams (e.g., from Subversion or CVS). The work item importer is
fairly generic, since it just reads from a particular data format file
(so you just need to dump your work items into that format, to get them
imported). The SCM importer is being generalized so that it can more
easily be applied to an arbitrary SCM repository (post a follow-up
message if you'd like more info on that from the SCM team).

Cheers,
Geoff

Geoffrey Clemm wrote:

The answer varies depending on the kind of Connector.

In general, a Connector provides a persistent link between an object in
one repository and an object in another repository.

A Connector is then classified in two ways:
- the kind of Connector, which is either a Synchronizer or a Bridge
- the types of objects being connnected

A Synchronizer links an object in one repository with a "proxy" for that
object that it creates in the other repository. Periodically, the
changes made to the object are automatically applied to the proxy, and
vice versa.

In contrast, a Bridge just provides a GUI for creating and traversing a
link between objects in different repositories.

Jazz provides two kinds of generic synchronizer machinery:
- the Item Synchronizer
- the Stream Synchronizer

The Item Synchronizer connects two records, and periodically (e.g. every
few minutes) synchronizes the fields in those two records. It is
designed so that although one side can be an arbitrary repository, the
other side is currently pretty much hard-wired to be the Jazz repository.

The Stream Synchronizer connects two SCM streams, and periodically (e.g.
daily) synchronizes the current configuration (the "tip") of those two
streams. It uses the WVCM API (defined in
http://www.jcp.org/en/jsr/detail?id=147) to talk to both repositories,
so it can be used to connect two arbitrary repositories that provide
support for the WVCM API.

Currently, the RTC bridges are all custom bridges, designed to connect a
particular type of object in one type of repository to another
particular type of object in another type of repository. For example,
there is the Subversion bridge, which connects a Subversion change-set
to an RTC work item. This is custom code, which only works with those
two repositories, but since the source is available, can be used as
guidance for how to write your own custom bridge.

Our goal going forward is to implement OSLC Bridges. These are bridges
that are designed to use the OSLC services (http://open-services.net) to
talk to a repository. These bridges are intended to be usable to
connect any two repositories that support the OSLC services. The
Bridges that we are currently working on that are designed to evolve
into OSLC bridges are the ClearCase Bridge (that links RTC workitems to
ClearCase activities) and the ClearQuest Bridge (that links RTC
workitems to ClearQuest change requests).

Cheers,
Geoff




crvich wrote:
Let's say hypothetically I wanted to bi-directionally bridge data
between, say, Bugzilla and the bug trackers on GForge. Or the CMVC
Files/etc. table data and Subversion.

Is the Connector technology in Jazz/RTC built in such a way that it
can provide general sync/bridging functionality like these examples
"outside" of the RTC domain? i.e., for situations where
users do not have a desire for full-blown RTC itself (JTS, etc.),
just its Connector functionality. Or is it purely intended for
connecting *RTC* with other data sources?

Thanks,
Ernest

The answer varies depending on the kind of Connector.

In general, a Connector provides a persistent link between an object in
one repository and an object in another repository.

A Connector is then classified in two ways:
- the kind of Connector, which is either a Synchronizer or a Bridge
- the types of objects being connnected

A Synchronizer links an object in one repository with a "proxy" for that
object that it creates in the other repository. Periodically, the
changes made to the object are automatically applied to the proxy, and
vice versa.

In contrast, a Bridge just provides a GUI for creating and traversing a
link between objects in different repositories.

Jazz provides two kinds of generic synchronizer machinery:
- the Item Synchronizer
- the Stream Synchronizer

The Item Synchronizer connects two records, and periodically (e.g. every
few minutes) synchronizes the fields in those two records. It is
designed so that although one side can be an arbitrary repository, the
other side is currently pretty much hard-wired to be the Jazz repository.

The Stream Synchronizer connects two SCM streams, and periodically (e.g.
daily) synchronizes the current configuration (the "tip") of those two
streams. It uses the WVCM API (defined in
http://www.jcp.org/en/jsr/detail?id=147) to talk to both repositories,
so it can be used to connect two arbitrary repositories that provide
support for the WVCM API.

Currently, the RTC bridges are all custom bridges, designed to connect a
particular type of object in one type of repository to another
particular type of object in another type of repository. For example,
there is the Subversion bridge, which connects a Subversion change-set
to an RTC work item. This is custom code, which only works with those
two repositories, but since the source is available, can be used as
guidance for how to write your own custom bridge.

Our goal going forward is to implement OSLC Bridges. These are bridges
that are designed to use the OSLC services (http://open-services.net) to
talk to a repository. These bridges are intended to be usable to
connect any two repositories that support the OSLC services. The
Bridges that we are currently working on that are designed to evolve
into OSLC bridges are the ClearCase Bridge (that links RTC workitems to
ClearCase activities) and the ClearQuest Bridge (that links RTC
workitems to ClearQuest change requests).

Cheers,
Geoff




crvich wrote:

Let's say hypothetically I wanted to bi-directionally bridge data
between, say, Bugzilla and the bug trackers on GForge. Or the CMVC
Files/etc. table data and Subversion.

Is the Connector technology in Jazz/RTC built in such a way that it
can provide general sync/bridging functionality like these examples
"outside" of the RTC domain? i.e., for situations where
users do not have a desire for full-blown RTC itself (JTS, etc.),
just its Connector functionality. Or is it purely intended for
connecting *RTC* with other data sources?

Thanks,
Ernest