[ https://jira.jboss.org/jira/browse/JBIDE-4191?page=com.atlassian.jira.plu... ] Aaron Pestel updated JBIDE-4191: -------------------------------- Attachment: ESB_Wizard_Proposals.pdf -- 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

[ https://jira.jboss.org/jira/browse/JBIDE-4191?page=com.atlassian.jira.plu... ] Aaron Pestel commented on JBIDE-4191: ------------------------------------- I think you are completely correct. I definitely understand your pain about it being a 100% manual process because I've done that process in a couple cases to find options that were not documented. The only thing I would say to that is that if the tooling team does it once, it will save many users from having to go through the same process many times. I've created some Jiras on the ESB team to document some of these options, but that's going to be some time before the documentation is updated and still if the options are not in the tooling, I think we'll have users stumbling. Maybe the tooling team can create blocking Jiras on all the underlying projects such that the underlying projects have to completely describe possible configuration options before going forward, which could then be used by the tooling developers. Maybe the wizards could be setup to have some generic aspects where there is some property or XML file in the plugin that lists the options for a given screen. In that case, it might be more easy to add additional options when we find them - basically add entries to an XML file that will change the options available in the wizard rather than having to change GUI code in the wizard. I'm not sure I know the right answer, but I know that I run across a fair number of users that think our ESB doesn't support certain things or think they have to custom code stuff because many of our options do not exist in the tooling and are also not well documented. The more users we get, the more I think this is going to be an issue for us. -- 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

[ https://jira.jboss.org/jira/browse/JBIDE-4191?page=com.atlassian.jira.plu... ] Max Rydahl Andersen updated JBIDE-4191: --------------------------------------- Fix Version/s: 3.1.0.M3 John - you got the ball on this one ;) -- 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

[ https://jira.jboss.org/jira/browse/JBIDE-4191?page=com.atlassian.jira.plu... ] Brian Fitzpatrick updated JBIDE-4191: ------------------------------------- Original Estimate: 0 minutes Remaining Estimate: 0 minutes Max, we're looking at this for 3.0, not 2.1, aren't we? -- 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

[ https://jira.jboss.org/jira/browse/JBIDE-4191?page=com.atlassian.jira.plu... ] Max Rydahl Andersen updated JBIDE-4191: --------------------------------------- Fix Version/s: 3.1.0.M4 (was: 3.1.0.M3) slip to next version. -- 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

[ https://jira.jboss.org/jira/browse/JBIDE-4191?page=com.atlassian.jira.plu... ] Brian Fitzpatrick updated JBIDE-4191: ------------------------------------- Would it be easier to focus on allowing users to create new ESB configurations based on existing quickstarts? I.e. Maybe I know I want to Proxy a web service, so I want to start from the "Basic WS Proxy" quickstart, change a few values, and run with it? I agree that we need more support once in the editor to add services, listeners, etc. But I'm wondering if we need to take a step up from the editor and get people started with a solid, established pattern (like those in the quickstarts) and let them take it from there. -- 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

[ https://jira.jboss.org/jira/browse/JBIDE-4191?page=com.atlassian.jira.plu... ] Aaron Pestel commented on JBIDE-4191: ------------------------------------- I can see value in that. Customers have asked for it (pull quickstarts into JBDS) and someone has added some of them via "File | New | Other... | JBoss Tools | Project Examples | ESB". However, it's only a subset of the quickstarts, customers have to be on the internet, and the clients don't always seem to work. In general though, I think a more general approach is preferred at least initially. If I can just right-click and choose "New ESB Service" and the wizard walks me through selecting a gateway (or creating if necessary) and actions (where all possibly gateways and actions are shown in a list - possibly categorized if too many actions), I think that would be more intuitive than starting from a template. It also helps them understand the components of an ESB service that they may miss if everything was just created for them. Also, just pulling in the templates still doesn't show all the options on each of the actions. There are a host of options that need to be set in a case like WS-proxy, especially if customer is doing HTTPS, Basic Auth, or something like that. Those are not covered in a single quickstart, so we'd risk the novice customer potentially creating a "ws proxy" and then concluding that it must not support ssl, basic auth, etc. since it's not in the "new WS proxy" action. In general though, I think it would be a good feature. Would just prefer that it come after we have a nice simple wizard driven way of creating services and actions in general. -- 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

[ https://jira.jboss.org/jira/browse/JBIDE-4191?page=com.atlassian.jira.plu... ] Brian Fitzpatrick updated JBIDE-4191: ------------------------------------- Fix Version/s: LATER (was: 3.1.0.CR1) Bumping this to LATER. As soon as Smooks stabilizes, I'll have time to start digging into the ESB editor. -- 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