Daniel, Thanks for the elaboration and pointer to the code you started. I added a "enhance" task to what you had in gae.rb and attached it. I'm not lingual in git yet so I wasn't sure how to add it there.
Thanks again, -Shane On Sat, Aug 15, 2009 at 3:19 PM, Daniel Spiewak <[email protected]> wrote: > Just to elaborate on this, we do accept submissions for inclusion in the > core Buildr addons, but they do have to go through a review process and > such > before we determine whether or not there is enough interest to merit > inclusion. A good, present-day example of this is the (still forthcoming) > checkstyle and pmd extensions, which have garnered considerable interest > and > are currently in the review/legal-release stage. > > As far as I'm concerned, GAE support would be very nice. You may want to > take a look at some preliminary work I've done in that direction: > http://github.com/djspiewak/buildr (gae branch). I'm less interested in > Flex, but I know there have been other community members in the past who > have commented on Buildr's lack of support and requested improvement (there > may even be an open issue in JIRA). > > Daniel > > On Sat, Aug 15, 2009 at 3:12 PM, Assaf Arkin <[email protected]> wrote: > > > 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 > > > > > > > > > > > > > > >
