A workflow (called_workflow) which is called by another workflow (calling_workflow) in your project is very much existing in your APDE project, but you still can't package the tcdriver. Every time you try to do so, the workflow2Java step fails with an error like:
message = cannot find symbol: method callThe reason for this as I guess is, the server side does not have a (updated) copy of the workflow in question (called_workflow), though its very much there in your local APDE environment! Hence when APDE tries to generate the Java code for calling_workflow (APDE uses the TPM server's copies of the workflows to generate the Java code for a workflow), it is not able to find the definition of called_workflow on TPM server and puts a statement like this into the generated Java code of call
ed_w orkf low( ),lo cati on: class com.ibm....
calAnd when this generated Java file is compiled, naturally the compilation fails, as there is no Java method called called_workflow()! This can be pretty frustrating (like me and my team-mates often were) to come around the situation. This is what I discovered as a work-around, after a lot of hit and trial:
led_ work flow (); //Workflow Not Found Error
- Clean your APDE project, running ant-command "clean" of the project's build.xml. This will remove all the generated Java files from the workflows.
- Open the workflow in question (called_workflow) and
compile it explicitly, using the Workflow -> Compile command from the
toolbar. This will compile the workflow and sync it with the TPM
Note: As an additional check, you can remove the TPM server's copy (if exists) from the workflow view before doing step 2 and check if the server's copy is regenerated after doing step 2.
package your project, running and-command "package" of build.xml. This
time the tcdriver should package fine, without the above error.