Team, The appserver stuff has some trickier logic than the typical plugin I think. This is causing a challenge for me to convert it to jelly, not to mention I am
feeling my way through jelly as it is. I'll try to explain what is going on here in hopes someone can offer some advice. The build file in question that needs converting is the j2ee build.xml We have an appserver-install target that copies the minimum required files needed to install a user instance of an appserver. The user therefore is familiar with the "appserver-install" target and treats it as a public goal for installing an appserver instance. Depending on the server status ( which may be installed and stopped or installed and started or not installed) the appserver-install target does different things. In the current ant code, I have discreet control over when a callback for the appserver-install target can be called. This is nice in that no matter what logic the appserver-install target does, I can make sure that a pre-appserver-install target defined by the user gets called only right before the actual atomic install. This comes into play for example in the following case: Suppose my server instance is installed and started and then as a user I type maven appserver-install. As written the code detects the server's current status ( installed and started) and interprets the user's action as wanting to reinstall the running appserver and return it to the started state. So the actions that take place are 1. Stop the server 2. re-install it 3. Restart the server You can see in this case that if the user has a pre-apserver-install goal it will actually get called before the server is stopped and after the server is started. Something like: 1a. call pre-appserver-install-callback 1b. Stop the server 2. re-install it 3. Restart the server But what I really want to do with jelly is something like: 1. Stop the server 2.a call the user's pre-appserver-install target 2.b re-install it 3. Restart the server Some ideas to solve this are: 1. Bury all this fancy logic in Java classes. ( So do I write something based off AbstractExecutor? and figure out how to invoke jelly targets from my classes only if the targets exist? Seems like this is like working the old way...and loses flexibility for the user to define any targets they want?? I just don't know enough about Jelly yet I guess) 2. Just tell the appserver-install user in documentation that if they really want a pre-appserver-install callback goal it has to point to say appserver-install-build ( see line 694 of j2ee build.xml )/ problem with this is it would be different than your typical 'public' goal' behavior. I don't like the inconsistency. 3. Bob mentioned I could use <attainGoal> to call the users callback goal in maven.xml. This would mimick the old callback approach wouldn't it? That can't be good... 4. Be more explicit and add an appserver-reinstall and appserver-restart target. This maybe helps the user be more accurate in defining their pre/post goals. However I don't like this idea because a) that means a total of six main goals for appserver and makes it more complicated. b) I like the smart status check the existing targets provide. By just calling one target the user gets a big bang for the buck. They don't need to keep track of and rely always knowing the current status of their server instance. I think I need some more ideas to solve this. Any out there? -Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
