Aaron Mulder wrote:
        I'd like to remove the current "deployer.jar" tool, remove the
command-line processing logic from the Deployer class, rename
"new-deployer.jar" to "deployer.jar" and change the bootstrapper to build
the new one instead of the old one.  Currently there are two so we'd have
some sort of transition (fallback in case of problems), but since the
build script is pretty much only using the new one now, there are some
NPE's in the old one, and no one seems to have had any problems with the
new one, I'd like to go ahead and eliminate the old one.

        Please indicate whether you agree.


I played with this briefly in online mode and in package mode and everything looked good. I still feel it is a little early as others may not have had chance yet but here's my +1


I do have a couple of suggestions for minor improvements. AIUI there is no option to package without installing in the deployer's config store; I think this would be a useful option to add. I would suggest making the default not to install and then add a --install option to the package command which would do that.

The other is that in the old one if you did not specify --install or --outfile then it effectively validated that the config could be built but did not do anything with it. This was useful if a little obscure. I would suggest added a "validate" command that did just that. I think this can work both online and in package mode although doing it online may mean working around JSR-88 limitations. We should also be clear that validate just means that the config can be built (which will catch 90% of common deployment problems) but will not actually try to start the config.

Thanks Aaron, I think this is a good improvement over what we had before.

--
Jeremy

Reply via email to