I totally agree, Jerome. As a matter of fact, 2 plugins I worked on recently were intially "Maven calling Ant task which calls the proper internal code" and then very shortly thereafter I changed them to "Maven calling internal code directly". These were new plugins (macker and ckjm) and fortunately it was very simple to use the internal classes, perhaps even easier than calling the Ant code.
This can be complicated of course when the target plugin does not make it easy for you to access the internals and get things set up properly. Or when the target is very unstable forcing you to change your own code often just to keep up with things. While it is frequently easier to call the Ant code, I think this is a poor practice in general for plugin developers, and I'd encourage everyone to avoid it unless you have specific reasons for it. Wayne On 8/28/07, Jerome Lacoste <[EMAIL PROTECTED]> wrote: > Hei, > > I have tried to use the latest selenium plugin and I am facing the > MSELENIUM-22 issue (selenese goal). > > This issue exhibits something I feel is dangerous to the maven > ecosystem. To use the plugin I have a groovy layer integrating with > ant calling the selenese ant task. > > How much runtime impact does this have on my build (memory, time) ? > Doesn't this become much harder to debug ? > > > Can't this be simplified ? Shouldn't we aim for simpler integrations ? > > When I try to design plugins, I try as often as possible to limit the > amount of layers between me and the target tool. Either I call the > executable, either I call the API, or if I don't have time, I > integrate with an existing ant task. > > Ideally I would like to see maven goals sit at the same level as ant > tasks, reusing an build tool agnostic API. > > I believe that for maven to be robust and fast we have to push the > "try to have plugins interact as close as possible to their target". > > I understand the fact that reusing an existing layer is tempting. But > does it serve us on the long run ? > > Thoughts ? > > -- > Jerome Lacoste > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
