Refactor the server task into several operation-specific tasks

[jgawor]

No description provided.

[jgawor]

Right now the 'server' task takes the 'operation' to execute as an attribute as well as several other attributes that are operation specific. For example, clean attribute can be set when executing the 'package' operation. The clean setting won't be used in this case.
It might be cleaner/nicer to refactor the 'server' task into several independent operation-specific tasks that only support attributes that are actually used by the operation. For example, we could have:

<wlp:serverCreate name="foo" template="bar"/>

or

<wlp:serverStart name="foo" clean="false"/>

or

<wlp:serverPackage name="foo" archive="foo.zip"/>

[jgawor]

Besides adding the operation-specific tasks we could also refactor the existing <wlp:server> task to remove the operation-specific parameters (such as 'timeout', 'clean', and 'archive') and replace it with generic 'arguments' parameter. That way, the <wlp:server> task would really become a thin wrapper for the 'server' command. For example, to create a server from a template the user could do:

<wlp:server operation="create">
  <argument>--template=bar</argument>
</wlp:server>

The operation-specific tasks could of course reuse this server definition via the 'ref' attribute. The operation-specific tasks would provide additional value adds such as better error checking, etc.

[MisaelSalcido]

On my branch issue3, I created a class that extends ServerTask for each server operation. Each class only sets the operation attribute to its respective operation and executes the do-Operation()- method. This avoids the rewriting of the same code, lets the Maven and Gradle project still work with the ServerTask class and provides backwards compatibility. The inconvenient is that the issue is still present, the user can write something like this:

<wlp:serverStop id="idMyServer" installDir="${wlp_install_dir}" template="notInUse" />

And I think there's no way to evade it without removing the compatibility with Maven and Gradle (Because both of them executes their operations using the setters of the ServerTask). Of course we could just hide the parameters not used in each operation in the README, what do you think?

[MisaelSalcido]

Also, I want to add the nested 'argument' element, but what if the user writes something like this:

<wlp:server operation="create" template="someTemplate">
    <argument>--template="someOtherTemplate"</argument>
</wlp:server>

I think that the user shouldn't do both add arguments and parameters at the same time.