It's all about the answers!

Ask a question

How do I copy a work item to another project area using the client java api

Richard Good (872560) | asked Apr 16 '15, 5:42 a.m.


I am working on a database migration script. I have successfully created a work item type to hold the migrated data in one project area (for reference only), but need to copy all these work items to another area in the new form (without old database details) and then link back. I have been using some of Ralph Schoon's very useful articles as a starting point. I was hoping for a IWorkItemClient saveas(IProjectArea NewProj) method. All I essentially want is a method that is the equivalent of the  "move/copy to project area" function in the eclipse client. Any pointers?

I might be being a bit thick , but I was hoping to create a new workItem of the required type then load the entire contents of another workitem over the top of it, but how to do this?

Thanks for any help


2 answers

permanent link
Ralph Schoon (63.2k33646) | answered Apr 16 '15, 6:01 a.m.
edited Apr 16 '15, 6:03 a.m.

why do you want to reinvent the wheel here? There is such a function available already in RTC.
If you want to reinvent the wheel, you would have to read every attribute in the source work item, then you have to find the matching data in the target attribute and set it. This is easy for simple attributes like strings, but for iterations, enumerations etc, you need a mapping by name or ID or literal mapping. Same for Team Area/List and other complex attributes.

Across repositories you will have to match all data (except trivial such as strings, ints, durations). That is, why it is not trivial to implement things like project move.

As an alternative have a look at the class. You can get this by opening the wizard in Eclipse and SHIFT+ALT+F1 it with the Plugin Spy.

Assuming you set up the SDK as described by me, you should now be able to see the source code of that wizard and look into the method performFinish() to figure out how the code does the move.


Richard Good commented Apr 16 '15, 6:13 a.m.

Hi Ralph,

Working to my customers requirement, they don't want the old database properties - bespoke attributes to pollute the new process model, but want them easily referenced until all they are closed off - hence two project areas with the same work items , but different types!! The eclipse function works perfectly if I only has a few, but I have many to do, I need to map the work items in the old database area to multiple work item types in the new are and ideally map the old database status to the new workflow status. I have queries to grab sets of work items using a variation of your work item query wrapper and was hoping to write a few simple functions to copy items from one area to another, then change type and status based on my customers criteria. Thanks for the  suggestion - I will have a look at this now. Thanks also for some of the excellent articles - they have aided the learning process no end and probably saved me weeks of struggle!


Ralph Schoon commented Apr 16 '15, 6:17 a.m.

Are you aware of this?

Otherwise it might be best to reuse the available wizard code.

Good luck!

permanent link
Richard Good (872560) | answered Apr 16 '15, 7:03 a.m.

Had a look at the copytoprojectarea code (excerpt below) and imagine that this could work (I can easily get some Workitemhandles to throw at it) I need to set the following properties from my java project then run the public copytoprojectarea method. Not sure how I can change the members to public and recompile - probably can't ;-) , (not as easy as extracting the java file changing the private to public then putting it back in is it?) or pump/ simulate the dialog box settings into the java class some how. Need to know how to cheat here!! Not an accomplished java user as yet. 

    private static final String DIALOG_SETTINGS_KEY = "copyToProjectArea";
    private static final String TARGET_AREA_KEY = "targetArea";
    private static final String MOVE_KEY = "move";
    private static final String RESOLVE_SOURCE_KEY = "resolveSource";
    private IDialogSettings fDialogSettings;
    private List<IWorkItemHandle> fWorkItems;
    private ITeamRepository fTeamRepository;
    private IProjectAreaHandle fTargetArea;
    private boolean fMove;
    private boolean fResolveSource;
    private boolean fMoveAttachments;
    private boolean fCopyAllowed;
    public CopyToProjectAreaWizard(List<IWorkItemHandle> workItems) {
        //compiled code
        throw new RuntimeException("Compiled Code");

Ralph Schoon commented Apr 16 '15, 7:32 a.m.

Jorge explains here how he created a custom wizard from existing code:

Richard Good commented Apr 16 '15, 7:36 a.m.

That looks like the way to go - thanks for the steer. I'll have a go and report back...

Richard Good commented Apr 16 '15, 11:27 a.m.

On reflection not sure how extending this class helps me, I still need to find some protected or public method to update the private properties with my criteria without running the wizard. No obvious candidates appear. It's a pain they are private not protected!

Richard Good commented Apr 16 '15, 12:05 p.m.

Note that I use Netbeans, I navigated to the source by referencing the jar file and I end up displaying the file, think that's all the information available here, but could be wrong, can't see inside performFinish method any further because it's compiled. May have to resort to creating two sets of work items initially and forget about making it more flexible and making it run from a query, disappointing though

Ralph Schoon commented Apr 16 '15, 1:15 p.m.

If you like to bind your hands in the back, wear sunglasses in the tomb and still expect to be able to examine findings, use Netbeans. If you want to see the code that I see, use Eclipse and follow this:

Richard Good commented Apr 17 '15, 3:35 a.m.

I'm picturing Lara Croft escaping from a bunch of rampaging mummies - this is not quite me ;-)

I'm a long time Netbeans user, been called upon to do support tasks on various applications and even written addins for rhapsody, rtc  and rpe using it. I like the ANT build scripts and the GUI builder. All IBM java addins assume eclipse use, but I seem to be able to translate everything to Netbeans fairly easily - no I'm not a masochist - well at least I think I'm not! Taking up eclipse is a bit like being asked to take up snow boarding when you are an expert skier, you know you can do it, you just can't be asked falling over all the time and you know you can easily get down the slope with the skis ;-) However, I will have a stab at using eclipse and setting it up using your article at some point

Ralph Schoon commented Apr 17 '15, 3:41 a.m.

If you at least do the setup to get to the code that is shipped with the SDK would be a great advantage to you.

I understand it is tough to change to another IDE though.

Richard Good commented Apr 22 '15, 10:55 a.m.

Bit the eclipse bullet a little, got a bit of indigestion. Do I really have to attach java docs to each and every RTC jar file I add to the plainJavaApi library?

Still can't believe there is apparently no graphical way to create dialog boxes in eclipse. I may be a bit alone in the wilderness, but I feel inclined to carry on with Netbeans. Resorted to running the same create workItems routines twice and used your link code to connect things together, gave up on using a query as the starting point in the end

Ralph Schoon commented Jul 05 '16, 10:33 a.m.

The setup of the extensions workshop should do that automatically for you.

showing 5 of 9 show 4 more comments

Your answer

Register or to post 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.