Bug 996881 - deploy.xml is not created automaticaly when using BPEL implementation for Component
deploy.xml is not created automaticaly when using BPEL implementation for Com...
Status: NEW
Product: JBoss Fuse Service Works 6
Classification: JBoss
Component: Tooling (Show other bugs)
6.0.0 GA
Unspecified Unspecified
low Severity medium
: ---
: ---
Assigned To: tcunning
Len DiMaggio
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-14 04:39 EDT by Jiri Sedlacek
Modified: 2015-08-02 19:47 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Enhancement
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker SWITCHYARD-1283 Major Open BPEL Engine should use switchyard.xml and deprecate the deploy.xml 2015-04-13 16:30:26 EDT

  None (edit)
Description Jiri Sedlacek 2013-08-14 04:39:55 EDT
If I add BPEL Component to switchyard project, Process.bpel file is created, but deploy.xml file is important for deployment too, and this file isn't created.

User has to create it separately by creating plain xml file. Moreover, deploy.xml, Process.bpel, switchyard.xml should be linked somehow, to let user set these files in confortable way. Now you have to know exactly which namespaces and names to fill there and if you change it in switchyard.xml, propagation to other files has to be done manualy.
Comment 1 Rob Cernich 2013-08-14 11:14:35 EDT
There is an outstanding enhancement request in JIRA to remove the requirement for deploy.xml altogether.

In addition to that, the issue with synchronizing switchyard.xml content with other artifacts in the project, in my opinion, falls under the broader scope of refactoring and is not solely limited to bpel.  It applies to all the implementation types.

That said, I don't think refactoring support will be available in the 6.0 timeframe.  Improved validation (for sure), and possibly "quick fix" support (hopefully) are probably as far as we'll get for 6.0.  In any case, I think we need to split this issue into multiple issues:
1. deploy.xml
2. refactoring
3. validation
Comment 3 Rob Cernich 2013-08-23 13:57:28 EDT
This is an enhancement request and will not make it in the 6.0 timeframe.
Comment 4 Rob Cernich 2014-10-21 15:37:12 EDT
I don't think this is going to make it into FSW 6.1
Comment 5 Len DiMaggio 2015-02-17 12:38:43 EST
Nacking this bugzilla - this is an EAP issue and FSW 6.2 will not embed EAP.
Comment 6 Ken Johnson 2015-03-12 14:53:56 EDT
This is low priority but is there anything we can do (doc, sample file) to make this easier?
Comment 7 Len DiMaggio 2015-03-16 11:50:48 EDT
Nacked in error! This is not an EAP issue.
Comment 8 Len DiMaggio 2015-03-16 11:51:54 EDT
A documented sample file would be a good solution.

Note You need to log in before you can comment on or make changes to this bug.