User development, The document "A good start!", was updated Mar 3, 2010 by Robert (Bob) Brodt. To view the document, visit: http://community.jboss.org/docs/DOC-14913#cf Document: -------------------------------------------------------------- Not just the punchline to an indelicate lawyer joke and a memorable quote from a 90's movie, “a good start” also describes the BPEL tooling that is offered as part of the http://in.relation.to/Bloggers/JBossTools31CR2CDILessTypingAndTheLastPolish. While this release focuses mainly on stabilizing existing tools and the addition of new features, the BPEL Editor User Experience (as I'm sure the JBossTools team will agree) still leaves much to be desired.   Besides having an incredibly non-intuitive user interface bordering on the user hostile, the eclipse BPEL Editor still has quite a few serious bugs and gaps in functionality. After having played with Riftsaw and the JBossTools for about a month, I came up with a list of fixes and enhancements I'd like to see implemented within the next few releases. Some of these are “nice to have”, others are a definite “must have”.   “Must have” Features: * Validation: While there has been a      great deal of work already done to improve the BPEL validation, I      still ran across some compilation errors that the in-built validator      did not catch. My recommendation would be to run the Riftsaw bpelc      compiler during a project build to ensure the bpel will compile.      Compilation is relatively fast and I don't anticipate this being a      huge problem if the user has “Build Automatically” enabled on      the eclipse Project. * Refactoring: Often times I find      myself changing the names of variables, port types, partner links,      etc. either in the Property sheet or directly on the editor canvas      without thinking; what I really wanted to do was refactor the name      change and have it propagate through to the WSDL or XSD where the      element is defined. It would be simple enough to provide a change      listener that prompts you with “Hey, I noticed you changed the      name of this <thing> - did you intend to refactor instead?”      possibly with a “Don't ask me again!” checkbox. The same      functionality should be provided for the WSDL and XSD editor. This      would go a long way to better integration within the tooling. * Better synchronization between      design & source views and Property sheets.   “Nice to have” Features: * Complex variable initialization      within Assign: this could easily be solved with the addition of a      button to the Assign Properties/Details tab which displays a      variables selection dialog. The editor could then generate the      appropriate XML to initialize complex variables. Apparently, the      Riftsaw engine requires the structure of complex variables to be set      before they can be accessed. * Debugging (really, really nice to      have): At the least I would like to be able to set breakpoints and      inspect variables at runtime; of course a full-featured interactive      debugger, which allows single-stepping, changing variables,      watchpoints, etc. would be nice to have. * “Follow link” capabilities      from the BPEL editor to WSDL/XSD and from WSDL editor to XSD for      messages, port types and partner links.   Must fix Bugs: * The namespace cache is not being      refreshed correctly when editing in source view. This causes some      strange validation errors, as message parts and variables may no      longer be resolved correctly. * The validator does not understand      return types of xpath functions; e.g. starts-with() returns boolean,      but when used in a condition, the validator reports this as “not a      boolean expression” * The concat() function argument      validation appears to have a bug; not all arguments are  recognized      correctly as variable references. * There appears to be some kind of      caching problem in the validator (unrelated to namespaces) which      prevents it from correctly resolving variable parts. Sometimes the      only way to remove Error Markers is to close and reopen a project.   I'd like to use this wiki document as a "wish list" for new features, so please feel free to add your $0.02 worth! --------------------------------------------------------------