Simplifying quickstarts

[dpalmer]

Hi eveyone

While testing the quickstarts for the last release it struck me that there were an awful lot of steps involved in executing some of the quickstarts. It would be nice if we could change the quickstarts so that the user only needed a standard set of steps. Ideally:

1. Start the application server

2. mvn install

3. mvn exec:java

4. mvn clean

5. Shutdown the server

With this in mind I produced a POC with the camel-jetty-binding quick start: https://github.com/douglaspalmer/quickstarts/tree/deploy_on_install/camel-netty-binding

I got most of the way there but I couldn't find a way to remove the file copy into standalone/configuration. We should get that with the CLI for wildfly.

If everyone agrees we could put the jboss-as:deploy on install and jboss-as:undeploy on clean into the quickstart parent. Then many quickstarts will just work. Some of the more complicated examples will need some cli scripts executing on clean and install. Quickstarts that don't deploy would need a deployment skip true adding to their pom.xml.

What do you all think of this idea?

Doug

[rcernich]

Sounds good to me.

I don't know how you all feel about this, but I think it would also be nice if the quickstarts were not parented by switchyard-parent and were stand alone projects instead.  This would more easily facilitate copy/paste reuse, allowing folks to get their own projects up and running quickly.  It would also illustrate how to use any bom that might be forthcoming (or already present).  Just an idea.

[kcbabo]

I'm +1 on the idea of build/test/deploy in one step.  I'm -1 on binding this to install as I don't feel it's natural/intuitive based on my typical use of install.  For example, I might go to the top-level of quickstarts and type "mvn clean install" expecting to build everything, but not expecting everything to deploy (and for any failures related to a target runtime not being started). 

What about putting this in a profile and then people can enable the behavior if they like it (e.g. mvn -PbuildDeploy install).  If people find they use that profile all the time, they can just activate it by default to eliminate the extra typing.

[kcbabo]

I like the idea of each quickstart becoming a standalone app, but dependency management (versions of dependencies) becomes a bit more of a pain without the parent definition.  I think what's missing here is a user-facing application BOM for SwitchYard.  If we had that, then the quickstarts could just import that at a given version level and everything else would line up.

[rcernich]

I agree. Having a bom would be the bom.

[kcbabo]

I agree. Having a bom would be the bom.

I just threw up in my mouth a little bit.

[dpalmer]

How about using a property instead of a profile? I have updated my camel-netty-binding with a property. 'mvn install' will still try to deploy to the AS; 'mvn install -Ddeploy.skip=true' will not deploy. 'mvn clean' will still undeploy; 'mvn clean -Ddeploy.skip=true' will not undeploy. Obviously we could reverse this logic but I think it's better to deploy by default.

I also updated it to execute the cli script with beforeDeployment/afterDeployment instead of invoking the execute-commands goal.

Regards

Doug

[dpalmer]

Forgot to mention that we would need to upgrade the version of the AS plugin for this to work properly. We need version 7.5.Final so that we can use conditional logic in the cli scripts. This is needed to protect against running the cli scripts multiple times.

Regards

Doug

[tcunning]

I'd like to see all the quickstarts successfully build and deploy even if the application server is running (i.e. profile off tests that need the AS stopped because of port conflicts or other issues).       There are a number that fail tests if the app server is up, and there's a number where I think we've had to tell people to skip the tests in order to deploy.      If users are in a training and running through a number of quickstarts, forgetting to stop the AS seems like the kind of thing that could bite them.

Also like the idea of as much consistency between quickstart steps as possible.

No opinion on jboss-as:deploy removal, I think that's pretty descriptive and it's something that users would have to do in their own projects.    

[dpalmer]

Your wish is my command. I fixed most of those issues for 1.1.0.Final; the tests still run but use a different port to the deployment. The only QS that still suffers from this is soap-mtom. I put a pull request in for it but it wasn't in time for the release. I guess it will be in the next release.

Regards

Doug

[kconner]

I suspect that overloading install/clean to also deploy/undeploy may annoy folk if this is made default as they would not expect it.

[mageshbk]

+1 to what Keith and Kevin says. I do not want the deploy/undeploy to happen by default. Nice idea Doug!

[kcbabo]

How about using a property instead of a profile? I have updated my camel-netty-binding with a property. 'mvn install' will still try to deploy to the AS; 'mvn install -Ddeploy.skip=true' will not deploy. 'mvn clean' will still undeploy; 'mvn clean -Ddeploy.skip=true' will not undeploy. Obviously we could reverse this logic but I think it's better to deploy by default.

I don't have a strong opinion on property vs. profile in this case, so either one works for me.

It's very important that the default (i.e. no property or profile activation) does not attempt to deploy and undeploy.