Tell users to provide extension for deployment via options or file-/directory-name

[odockal]

I was a bit confused that I actually could choose a folder with deployment (without need to name it xxx.war beforehand) when deploying to the wildfly server. I chose a folder and got hint "Do you want to edit optional deployment parameters?" which correctly guided me to choose a name for new deployment with war suffix, but still, it was not clear in the beginning.

[adietish]

steps:

1. ASSERT: have a wildfly server
2. EXEC: pick "Add deployment to server" in ctx menu
3. EXEC: choose a folder (exploded deployment) that has no extension in it's name
4. EXEC: when asked to provide Options (Yes/No?) say No

Result:
Deployment fails without giving any reason in the error dialog. See #345

Expected result:
Should have guidance that instructs user to provide a deployment type either via the folder-name or via the deployment options.
Then the error should say why adding the deployment failed (see #345 )

[robstryker]

Current code is as follows:

	for( int i = 0; i < supportedSuffix.length; i++ ) {
		if( hasSuffix(outputName, supportedSuffix[i]))
			return Status.OK_STATUS;
	}
	return new Status(IStatus.ERROR, Activator.BUNDLE_ID, 
			NLS.bind("Server {0} does not support deployment of resources without an approved suffix. " + 
	"Use the " + ServerManagementAPIConstants.DEPLOYMENT_OPTION_OUTPUT_NAME + " deployment option to override the output name.", server));

Doesn't this fix the issue?

[adietish]

@robstryker error is helpful, no doubt. But we should also inform upfront, before the users possibly runs into the error.
To me things are currently still non-obvious:
When adding a deployment how would you know that you have to say "Yes" if you add an exploded deployment where the folder isn't named "xxxxx.war"?:

It's only once you accepted to provide optional parameters that you discover that you need to provide the extension:

For the noob user this leads to the following unsatisfactory user experience:

1. add deployment -> point to exploded deployment
2. optional parameters -> No

Result:

Adding the deployment fails. The errors hints to you what's missing but you have no idea that providing optional parameters is how you'd be able to provide the extension and fix this. And then, this is too late, you need to go through a 1st unsuccessful cycle.

[robstryker]

I agree with you. I welcome specific suggestions on whether the language of the error message needs to change, or the API, or the workflow.

[robstryker]

But we should also inform upfront, before the users possibly runs into the error.

How can we inform the user upfront? The rsp-server itself has no ability to inform anything since no request has been made of it yet (ie you didn't attempt to add a deployment yet).

Furthermore, I don't believe the UI can possibly know what conditions could cause a deployment to fail without hard-coding specific situations for specific server types. So I'm not sure how we can accomplish this goal.

[lstocchi]

Currently, if a user uses Windows or Linux he has the ability to choose/specify which deployment he wants to add to the server through the quickpick (file or exploded).

We could remove the step where we ask the user if he wants to edit optional deployment parameters if he choose the exploded option. Is there any reason he could answer 'No' in this case? If not, it's useless to keep this step, it's obvious the answer will be a yes and we can skip this question.

We could have a problem in Mac OS because in this case we currently don't show any quickpick but we can change this part as well and make all OSes work in the same way.

[robstryker]

Simply removing the quickpick is not good. What if a server type such as karaf or something (making this up) can perform exploded deployments with no suffix but still has other optional attributes it may want the user to be able to fill out?

Remember, a protocol must work for as many runtimes as possible. It has to be as generic as possible. Your suggestion here would make ALL optional parameters either become required or disappear if the user is doing exploded deployment on any runtime. Bad idea.

The only other option I can see is to change the add-deployment into a workflow with many steps, but, this will probably have a lot of negative effects not just on code but also on usability for the user. But if this was a multiple-step process, a server adapter (like WildFly) could first analyze the prospective deployment and then come up with its list of optional vs required attributes.

But this would require a LOT of work, a re-org of part of the protocol, and would really slow down the process for the user. I think it's a bad idea.

We basically have two choices here: either define a static workflow for this action, and force everyone to use it no matter its deficiencies, or design a dynamic workflow for this action, which may be much more complicated, force the UI to handle a dynamic process, and slow down the request for the user substantially...

[robstryker]

Perhaps this would be best solved with a webview workflow where all options can be visible at once instead of the horrific quickpick implementation?

[odockal]

So adding web view form instead of input box when adding deployment?

[odockal]

If yes, then yes - it could be more informative for user.