From: <[EMAIL PROTECTED]>
[snip]
> 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
You could do something like this in the plugin.jelly file...
<goal name="appserver-install">
<attainGoal name="appserver-stop"/>
<attainGoal name="appserver-reinstall"/>
<attainGoal name="appserver-start"/>
</goal>
Then if a user wishes to perform step 2a, to do something before the
'reinstall' happens then they could add something like this to the projects
maven.xml document...
<preGoal name="appserver-reinstall">
... do something ...
</preGoal>
> 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)
By all means go that way if you wish. All you need to do is create a bean
which has some kind of 'run()' method (or execute() or invoke() or
something) that performs the action you wish along with some bean
properties. You can then bind that bean to a tag (I've been referring to
these as JellyBeans ;-).
e.g.
public class MyTask {
// 'doIt' method that does some function/task...
public void run() throws SomeException {
// do something...
}
// Properties, can be any type
public void setX(int x) {
this.x = x;
}
public void setY(String y) {
this.y = y;
}
}
Then you can use this bean in a script by defining a new tag library and
then using the new tag as follows...
<j:jelly xmlns:j="jelly:core" xmlns:define="jelly:define"
xmlns:my="myTagLib">
<define:taglib uri="myTagLib">
<define:jellybean name="foo" className="MyTask"/>
</define:taglib>
Now lets use the new tag
<my:foo x="2" y="cheese"/>
</j:jelly>
This mechanism is kinda similar to using a <taskdef> in Ant except that the
bean can be anything, it doesn't need to derive from Ant's Task - it can be
any java object with some kind of 'doit' method which takes no arguments.
(Indeed the method name can be set via <define:jellybean method="doIt"/>
> 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.
I don't quite follow. You should be able to attach a pre/post goal callback
easily.
> 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...
The problem with the old callbacks wasn't the concept, of plugging in some
custom build instructions into Maven's builds, it was the implementation
mechanism of using 2 properties in project.properties to call back an Ant
target and then all the horrible conditional logic in the plugins build.xml.
Now that the implementation mechanism is nice and simple now using Jelly +
Werkz, callbacks are a Good Thing (tm) :-)
> 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.
This could be good in that folks get to do stuff at exactly the right
points...
> 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?
I don't totally understand what you're trying to do. If you're worried about
the number of goals, you could make most of them private. Or I guess you
could have 1 goal called 'appserver-install' which then does its own thing
in whatever logic you wish, and just invokes a single goal
'appserver-usercallback' which could be empty but allow a single point at
which the user can invoke their own custom logic without them having to
totally understand how 'appserver-install' works? Or the 'appserver-install'
could be more explicit so users can register a callback when stuff gets
reinstalled, started, stopped etc. I guess its your call really.
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
