Aaron,
I don't think you have concisely explained what you want to do that is different from the status quo, and this is why no one is rallying around your proposal.
Also this "vote" is in the form of a poll (select from choices) instead of a vote (+1/-1 for a specific idea).
-dain
-- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26
On Oct 25, 2004, at 7:44 PM, Aaron Mulder wrote:
I only got one vote on this, and it wasn't from a committer. Please everyone take a look and send along your vote.
Thanks, Aaron
---------- Forwarded message ---------- Date: Sat, 23 Oct 2004 14:46:41 -0400 (EDT) From: Aaron Mulder <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Vote: 1 deployment tool or 2?
It looks like we'd like to have a command-line deployment tool with JSR-88 features. This would be aimed at providing hot deploy and start/stop and other JSR-88 features, as well as operating on remote servers. It could use the same logic as the Maven plugin or otherwise, I'm not concerned about the implementation yet. The question is:
[ ] Add these features to the existing bin/deployer.jar tool [ ] Create a new bin/xyz.jar tool with only these features, so we have an "offline" deployer and a "JSR-88" or "J2EE" deployer.
The advantage to the unified tool is that you'd have one deployer tool for any scenario. One command to remember, etc.
There are a couple advantages to having separate tools:
* If combined into one tool, the help would need to be rewritten to make
the 2 usage modes clear. For example, JSR-88 can't handle creating a
CAR or executable/classPath information, while the current deployer
can't handle start/stop/undeploy/etc. Also there would need to be
substantial syntax checking to avoid mixing parameters from different
modes. It seems unfortunate that a lot of the command line arguments
would clash with each other.
* The code for a unified tool would need to decide how to operate based
on the mode, and some operations (install/distribute) would need two
code paths for the same operation, making it harder to have clean code.
* The JSR-88 features of a combined tool might work against other servers
(given an appropriate plugin), but the other features would not, which
would also need to be clarified.
* The current deploy tool would not depend on JSR-88, making it possible
to have a more compact Geronimo distribution with a functional
deployer, granted without remote deploy or other JSR-88 features.
Anyway, please vote.
Thanks, Aaron
