[JBoss JIRA] Created: (GPD-134) form file names generated from the task dialogue are unstable
by Ross McDonald (JIRA)
form file names generated from the task dialogue are unstable
-------------------------------------------------------------
Key: GPD-134
URL: http://jira.jboss.com/jira/browse/GPD-134
Project: JBoss jBPM GPD
Issue Type: Bug
Components: jpdl
Affects Versions: jBPM JPDL Designer 3.1.0.beta1
Environment: osx macbook pro, eclipse 3.3.0
Reporter: Ross McDonald
Assigned To: Koen Aers
Priority: Minor
the form names generated from the task dialogue are sensitive to content...
'fbm-rejects.xhtml' is ok, and is stored in the DB fine when deployed,
'fbm-rejects-psr.xhtml' is not stored in the DB when deployed and therefore the form does not display within the jbpm-console
the DB schema says the name field is varchar(255), which suggests that perhaps the second hyphen in the name is causing a problem somewhere
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Created: (GPD-67) GPD support for editing non-files (any IEditorInput, not just FileEditorInput)
by John Ruud (JIRA)
GPD support for editing non-files (any IEditorInput, not just FileEditorInput)
------------------------------------------------------------------------------
Key: GPD-67
URL: http://jira.jboss.com/jira/browse/GPD-67
Project: JBoss jBPM GPD
Issue Type: Feature Request
Reporter: John Ruud
Assigned To: Koen Aers
Priority: Minor
We need to edit process defs that are stored in a DB, as opposed to the processdefinition.xml, gpd.xml files stored in the workspace. There are currently many dependencies to FileEditorInput/File throughout GPD (as is the case for a lot of other Eclipse editors BTW).
It would be very helpful if it would be feasible to separate out the code that deals with a particular type of IEditorInput from the rest of the editor, possibly into a separete delegate class. For FileEditorInput the delegate would deal with reading, writing, and syncronizing the view (resource listeners), plus whatever else I may have forgotten. We could then replace the default "file" delegate with our own that knows how to deal our DB (by subclassing of the editor would be fine).
Probably not the #1 GPD issue for many other users, but hopefully something you would keep in mind...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Created: (GPD-231) Editing task node's name in source view breaks XML, if used
by N/A N/A (JIRA)
Editing task node's name in source view breaks XML, if used
-----------------------------------------------------------
Key: GPD-231
URL: https://jira.jboss.org/jira/browse/GPD-231
Project: JBoss jBPM GPD
Issue Type: Bug
Affects Versions: jBPM jPDL Designer 3.1.3.SP2
Environment: Windows XP SP3, Eclipse 3.3
Reporter: N/A N/A
Assignee: Koen Aers
When switching to source code view and manually editing a task node's name which is used by an existing transition, breaks the XML. You can enter whatever you like, but the task's name attribute stays the same while the transition's to-attribute is cluttered with parts of the characters you have enter. Depending on whether you use backspace, the cursor may also jump around in the document, erasing some unrelated code.
Here is an example:
BEFORE
<start-state name="First step">
<task name="First step" swimlane="Role">
<controller>
<variable access="read,write,required" name="someVar" mapped-name="Some Var"/>
</controller>
</task>
<transition to="Second step"/>
</start-state>
<task-node name="Second Step"> <!-- CHANGE THIS -->
<task name="Second Step" swimlane="Second role">
<controller>
<variable access="read,write,required" name="someOtherVar" mapped-name="Some Other Var"/>
</controller>
</task>
<transition to="Third step"/>
</task-node>
AFTER
<start-state name="First step">
<task name="First step" swimlane="Role">
<controller>
<variable access="read,write,required" name="someVar" mapped-name="Some Var"/>
</controller>
</task>
<transition to="Second"/> <!-- broken -->
</start-state>
<task-node name="Second Ste> <!-- broken -->
<task nme="Second Step" swimlane="Second role"> <!-- broken (nme instead of name) -->
<controller>
<variable access="read,write,required" name="someOtherVar" mapped-name="Some Other Var"/>
</controller>
</task>
<transition to="Third step"/>
</task-node>
Another option is adding something to the node's name... First look at the original once more, when trying to add " Part 1" to "Second Step" (so it should be Second Step Part 1) we get this as the result:
<start-state name="First step">
<task name="First step" swimlane="Role">
<controller>
<variable access="read,write,required" name="someVar" mapped-name="Some Var"/>
</controller>
</task>
<transition to="Second step Part 1"/> <!-- changed, even though i edited the task-node's name-attribute -->
</start-state>
<task-node name="Second Step"> <!-- unchanged -->
<task name="Second Step" swimlane="Second role">
<controller>
<variable access="read,write,required" name="someOtherVar" mapped-name="Some Other Var"/>
</controller>
</task>
<transition to="Third step"/>
</task-node>
This can be worked around by first changing the transition's to-attribute to something that isn't used, but it's nonetheless a bug which causes some grief.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Created: (GPD-193) Add the ability to drag new components into the workflow
by Gunnar Hillert (JIRA)
Add the ability to drag new components into the workflow
--------------------------------------------------------
Key: GPD-193
URL: http://jira.jboss.com/jira/browse/GPD-193
Project: JBoss jBPM GPD
Issue Type: Feature Request
Reporter: Gunnar Hillert
Assigned To: Koen Aers
In the workflow designer it would be nice if I could simply drag a new workflow component into the main workflow.
Right now you have to select the component from the component palette and then click again in the main workflow area to place the component. This seems to be slightly less intuitive than just drag-and-drop the new component into the workflow.
Also, it would be great if I could then drag a component from the palette onto an existing 'transition line' and the transition will automatically connect to the newly placed component.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Created: (GPD-192) Remove need for jBPMRuntime in jDPL Designer
by Jeff DeLong (JIRA)
Remove need for jBPMRuntime in jDPL Designer
--------------------------------------------
Key: GPD-192
URL: http://jira.jboss.com/jira/browse/GPD-192
Project: JBoss jBPM GPD
Issue Type: Feature Request
Reporter: Jeff DeLong
Assigned To: Koen Aers
jPDL designer should be enhanced to not require the entire jBPM suite download to be configured as the jBPM Runtime, but instead include bpm-jpdl.jar, version.xml and whatever other files are required in a jBPM library which could be included as part of the plugin installation. Currently the jpdl designer requires this design tool to have access to jbpm source code, etc, which many process designers would not typically have. It also will make it easier packaging for the SOA-P.
Also, the drools plugin has a feature that allows the user to take an existing project and "Convert to Drools Project", which essentially adds the drools library jars to the project classpath. This is a really handy feature, because it does not force developers to start out as a drools project (which project type should I use if I want to include both jbpm and drools?). It would be nice if jPDL designer had a similar capability, where you could just say "Convert to jBPM Project", and it added the jbpm library jars to the classpath. In this way the SOA Platform IDE plugins (jBPM and Drools) would work in a similar way wrt to classpath, project structure, etc.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months