>> If I before said that deploy only should always be in started mode then I'm stupid - I >>only remember deploy only mode having the problem of not being able to be started - it >>just sat there and you had to manually invoke publish.
>This is not true. The deploy only server had an automatic-success start method, and you >demanded, for your demos, that this was unacceptable and that it must start in "started" >mode at all times since it's only purpose is to deploy. You said it hurt your demos to >have to explain why you create a deploy only server, and then "start" something that >doesn't actually "start". You then directed me to open a jira and change it. This was the >jira: https://issues.jboss.org/browse/JBIDE-8671
Funny, when I read JBIDE-8671 I still read it as it should allow a Start/Stop mode and go into starting.
But anyway - Deploy only server was a different beast without the nice "assumed started" feature we now got. We should align these things.
>And honestly your point back then was completely valid. If a deploy-only server's only >job is to deploy, then it should begin in state 'started' and always be deploying, and if >the user does not want to deploy, then he should disable automatic publishing for that >server. But, as a deploy-only server is most-often used to deploy, it should default to >automatic publishing, and it can only do that when started.
I disagree now that I have had a running server running on the directory deploy only server adapters goes against.
>I'm still not exactly sure what you want, or if what you want is possible.
It worked fine before this fix. The server adapter started deploying when I press Start, it stops deploying when I press stop. Easy and simple to explain.
>You basically want two separate functions: having start/stop "connect or disconnect", or >having start/stop "actually start or stop" a server. However having a start/stop who's >only job is to "connect or disconnect" basically just means publish or not publish... >which is the exact same thing as turning off automatic publishing for that server... no?
Turning off automatic publishing is cumbersome and doesn't work on a "running" server.
And yes, I would prefer if WTP had some other "state" it can represent but it doesn't so we'll have to live within those limitations.
For me the start/stop is start/stop of the server adapter; not the exact server. What start/stop does is then up to the server adapter to interpret.
>If I'm wrong I'd love to hear more thoughts on it, but for now I'm still baffled as to >what exactly you're looking for.
What was done before - that the AS server adapter is in "stopped/not-started" mode by default - that start button starts the server adapter (aka. automatic publishing and if managed server then start the server); and stop button stopts the server adapter (aka. automatic publishing stops and the if managed server then we gracefully attempt to stop the server)
At the moment, this is by design. Max's specific use case involves demanding no launches (and thus no polling) so that he can "publish" in an AS7-type method, to another workspace folder. Then, he wants it to commit to git. In order for wtp to automatically publish all the time, the server must be in 'started' mode.
Max? Any thoughts?