buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shane Witbeck <sh...@digitalsanctum.com>
Subject Re: procedure and tips for creating a Buildr plugin?
Date Sun, 16 Aug 2009 18:51:24 GMT
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 <djspiewak@gmail.com> 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 <assaf@labnotes.org> wrote:
>
> > On Sat, Aug 15, 2009 at 11:54 AM, Shane Witbeck <
> shane@digitalsanctum.com
> > >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 <djspiewak@gmail.com>
> > > 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 <
> > > shane@digitalsanctum.com
> > > > >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
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message