On Sat, Aug 15, 2009 at 11:54 AM, Shane Witbeck <[email protected]>wrote:
> Daniel, > > Thanks a lot for the overview of extensions. I was actually more interested > in addon's found in addon/buildr such as openjpa.rb. My apologies for not > being more clear with my naming of plugins vs. addons vs. extensions. Maybe > a better question to start would have been: When is it appropriate to > create > an addon vs. an extension? > > The topics I'm interested in creating an extension for is around Flex and > Google App Engine for Java. GAE uses some bytecode enhancement similar to > the OpenJPA addon that I'd like to be able to do from Buildr. > > I'm familiar with extensions but I was under the impression that something > more robust in the works regarding a plugin framework. I think it was Assaf > who mentioned it in a thread a while back. > > If extensions is meant to be the primary means of "extending" Buildr, > should > there be a less "ad-hoc" way of distributing them? There's a very robust extension API. We know it's robust because most of Buildr is written in the form of extensions (compile, test, package, etc are all extensions to a very small core). There are several ways to distribute extensions: - Put them in the same place (e.g. ~/.buildr) and require them from your buildfile - Put them in the project, typically under the tasks directory - As Ruby gems and specify which gems are used in the settings file At some point in the past I split the Buildr code base in two. If it was a core feature and well tested it went into core. If it wasn't a core feature, or simply untested, it went into addon. The idea was to extract some addons into separate plugins (e.g. OpenJPA is a good candidate) and shame other addons into getting test coverage and entering core (e.g Jetty). Assaf > > > Thanks again, > > -Shane > > > On Sat, Aug 15, 2009 at 1:06 PM, Daniel Spiewak <[email protected]> > wrote: > > > Actually, this is pretty much all you need to know: > > http://buildr.apache.org/extending.html#extensions These docs were > enough > > to get me up and running, building my first extension not so long ago. > > Buildr doesn't have formal plugins in the Maven sense; extensions require > a > > lot less ceremony. All you need to do is create the extension according > to > > the documentation previously linked, place it in a .rb file and require > > that > > file from within your buildfile. It's pretty much as simple as that. > > > > Distribution of extensions is usually pretty ad-hoc. However, it is > > possible to package up a Buildr extension as a Ruby Gem, which can then > be > > uploaded to the Rubyforge repository and made accessible to all Buildr > > users > > through the following mechanism: > > http://buildr.apache.org/more_stuff.html#gems > > > > As for best practices, usually you will want to RDoc any major methods. > > Testing is nice, but it can be a little difficult to setup a formal test > > suite for a simple extension (Buildr's own test suite has some fairly > > extensive infrastructure to ease this process). All of my "for self" > > extensions have been tested mainly by hand (yeah, I'm lazy). > > Architecturally, you should follow the example set by the Java compiler > > (lib/buildr/java/compiler.rb). Buildr itself is just a set of extensions > > (even "core" functionality), so examples abound if you're willing to look > > at > > the source code. > > > > Daniel > > > > On Sat, Aug 15, 2009 at 11:19 AM, Shane Witbeck < > [email protected] > > >wrote: > > > > > I'm looking for docs (other than looking at existing plugins) to help > me > > > determine the steps for building a plugin. Does anything like this > exist? > > > Any tips in terms of what a complete plugin should have (ie. tests, > etc.) > > > before submitting it would be helpful as well. > > > > > > If formal docs on this topic don't already exist, I think this would be > a > > > big help to Buildr and it's users. > > > > > > Thanks, > > > > > > -Shane > > > > > >
