Stephen Connolly wrote: > 2008/12/18 Luke Patterson <[email protected]> > > >> For most situations, you could consider the plugin artifact to be >> prez-layer. You are using the mojo injection mechanism and maven api >> to gather input for the utility-artifact/wrapped-tool to process. >> >> Is that consistent with what you were saying Stephen? >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> > Sort of. > > The key point is that the plugin has the Mojo... the annotations will be > injected into the Mojo... the Mojo's execute method then passes the > parameters to the worker class... the worker classes *do not* extend > AbstractMojo or any kind of Mojo.... if fact it's as if they don't know > about Mojo at all... otherwise were back to the same problem again. > If we talk web development, you mean business logic by worker class, and Mojo is just the class that extract the data from the plugin config (pom) then passes these data to the business logic. Ok, I see now the big picture. But then, > Put the worker classes in a separate jar, leave the classes extending > AbstractMojo in the plugin, and have the plugin depend on the worker classes > jar. > Where does my new mojo fits ? If I separate the logic in a jar artifact (which by the way the author of the docbkx did a great job on that) and leave the old mojo, then where does the modification goes? In a new mojo, in the original one ? in the pom (set the default values) ? > Examples of this pattern would be in some of the plugins (I suspect the > enforcer and resources plugins would be good examples) > I am looking into this now http://maven.apache.org/plugins/maven-enforcer-plugin/usage.html , and will check out the source soon. > -Stephen > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
