Feedback on Hudson Plugins
Locked
 
|
|
Administrator
|
In reply to this post by Douglas Squirrel
Douglas Squirrel wrote:
> Hi Hudson friends! > > I presented a session on my experience in writing a Hudson plugin (http://wiki.hudson-ci.org/display/HUDSON/slave-status) at the CITCON conference in Paris last weekend (http://citconf.com). Several plugin developers commented on the things they find useful and less useful when writing plugins, and we listed some of the plugins we would like to work on or see developed. If you are interested in this feedback please have a look at http://citconf.com/wiki/index.php?title=HudsonAndOtherPlugins. I'd be happy to discuss further with anyone. > > Thanks for providing a great extensible CI system! Thanks for the feedback. I must admit that I consider myself an Maven expert, so it hurts my ego to see this :-( On more serious notes, I wonder if we can do more of Jelly related static error checks, either inside IDE, or as tests. We recently started doing a bit of those --- Jelly files in the core are parsed and JEXL syntax checked during tests, and this is being expanded to plugins. The placement of the file can be something we can check --- if we find Jelly files not collocated with any source code, maybe we can flag that as an error. Checking required attributes of tags and making sure tags that are invoked exist could be another. But I think people out there probably know more about the kind of mistakes they've made in the past, and those input would be helpful. -- Kohsuke Kawaguchi Sun Microsystems http://weblogs.java.net/blog/kohsuke/ |
smime.p7s (4K)
|
|
Administrator
|
Jesse Glick wrote:
> Kohsuke Kawaguchi wrote: >> On more serious notes, I wonder if we can do more of Jelly related >> static error checks, either inside IDE, or as tests. We recently started >> doing a bit of those --- Jelly files in the core are parsed and JEXL >> syntax checked during tests, and this is being expanded to plugins. > > maven-hpi-plugin could run these checks, assuming they are quick. Closest you can get to compile-time warnings. For IntelliJ I have an IDE extension that checks them, so I guess I must have thought it's better to do it as a test. -- Kohsuke Kawaguchi Sun Microsystems http://weblogs.java.net/blog/kohsuke/ |
|
|
|
|
Administrator
|
In reply to this post by Douglas Squirrel
Douglas Squirrel wrote:
> Glad the feedback was useful to everyone! Some checks on Jelly file > locations would be really helpful, as I found it nearly impossible to > get mine in the right spot. For instance, if the file is for > com.youdevise.hudson.FooClass and it is supposed to be in > src/main/jelly/com/youdevise/hudson/FooClass/jelly (or whatever the rule > is) it would help to get an error if it appears anywhere else. OK. Maybe I can use a bit of annotations to designate mandatory views. > Kohsuke, didn't mean to malign your Maven expertise - I just remember > that as I struggled mightily to guess the right pom.xml settings for my > plugin, even you sometimes weren't sure what my weird errors meant or > how to avoid them. See > http://www.nabble.com/Re%3A-Improving-plugin-release-instructions-p23209900.html, > item 3, for an example where the Maven errors puzzled everyone [grin]. Yes, yes, I accept that :-) > ________________________________________ > From: Kohsuke Kawaguchi [[hidden email]] > Sent: 24 September 2009 23:38 > To: [hidden email] > Subject: Re: Feedback on Hudson Plugins > > Jesse Glick wrote: >> Kohsuke Kawaguchi wrote: >>> On more serious notes, I wonder if we can do more of Jelly related >>> static error checks, either inside IDE, or as tests. We recently started >>> doing a bit of those --- Jelly files in the core are parsed and JEXL >>> syntax checked during tests, and this is being expanded to plugins. >> >> maven-hpi-plugin could run these checks, assuming they are quick. Closest you can get to compile-time warnings. > > For IntelliJ I have an IDE extension that checks them, so I guess I must > have thought it's better to do it as a test. > > -- > Kohsuke Kawaguchi > Sun Microsystems http://weblogs.java.net/blog/kohsuke/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > -- Kohsuke Kawaguchi Sun Microsystems http://weblogs.java.net/blog/kohsuke/ |
|
Administrator
|
In reply to this post by Erik Ramfelt
I captured this thread in https://hudson.dev.java.net/issues/show_bug.cgi?id=4570 Erik Ramfelt wrote: > On Thu, Sep 24, 2009 at 20:38, Kohsuke Kawaguchi > <[hidden email]> wrote: >> Douglas Squirrel wrote: >>> Hi Hudson friends! >>> >>> I presented a session on my experience in writing a Hudson plugin (http://wiki.hudson-ci.org/display/HUDSON/slave-status) at the CITCON conference in Paris last weekend (http://citconf.com). Several plugin developers commented on the things they find useful and less useful when writing plugins, and we listed some of the plugins we would like to work on or see developed. If you are interested in this feedback please have a look at http://citconf.com/wiki/index.php?title=HudsonAndOtherPlugins. I'd be happy to discuss further with anyone. >>> >>> Thanks for providing a great extensible CI system! >> >> Thanks for the feedback. I must admit that I consider myself an Maven >> expert, so it hurts my ego to see this :-( >> >> >> On more serious notes, I wonder if we can do more of Jelly related >> static error checks, either inside IDE, or as tests. We recently started >> �doing a bit of those --- Jelly files in the core are parsed and JEXL >> syntax checked during tests, and this is being expanded to plugins. >> >> The placement of the file can be something we can check --- if we find >> Jelly files not collocated with any source code, maybe we can flag that >> as an error. Checking required attributes of tags and making sure tags >> that are invoked exist could be another. >> >> But I think people out there probably know more about the kind of >> mistakes they've made in the past, and those input would be helpful. > > Many times Ive had issues trying to get data from the descriptors to > the jelly files and back. Sometimes the objects in Jelly files are > referred as instance, it or something else. Some kind of standard > would be nice. point is next to impossible. Perhaps introducing some type annotation might be useful --- so that we can say something like: BuildStep should have config.jelly and if it does, "it" points to AbstractProject, "instance" points to ThisType, and "descriptor" points to its descriptor, in a machine-readable way. > Also, ive forgotten to add setters in my classes and i coudlnt > understand why it could retrieve data but not set it. So, if hpi:run > could add some logic to show a warning (or exception) if a jelly field > could not be set properly. I don't think Jelly is used to set anything --- you mean forgetting to define getters? > The HudsonTestCase helps with the jelly part, but it isnt very fast. I think we can and should improve this, especially with parallel execution of tests. -- Kohsuke Kawaguchi Sun Microsystems http://weblogs.java.net/blog/kohsuke/ |
Loading...
| Powered by Nabble | Edit this page |