Awesome! Thanks for the guide. I will get setup and let you know when I have my additions available.
-Shane On Sun, Aug 16, 2009 at 6:08 PM, Daniel Spiewak <[email protected]> wrote: > Actually, Apache mailing-lists seem to filter out attachments, so I never > got the file you sent. However, I can do you one better... > > *Presenting: Daniel Spiewak's Thirty Second Guide to Contributing to Buildr > using Git! > * > (ok, only thirty seconds if you type *really* fast) > > Step one: create a GitHub account. > Step two: clone the apache/buildr repository ( > http://github.com/apache/buildr) using the cleverly disguised button at > the > top. > Step three: hit the little "paste icon" next to the "Your Clone URL". > Step four: install Git (use MsysGit on Windows). > Step five: run the following command in the directory you wish to contain > your buildr directory (paste the URL from earlier where indicated): > > $ git clone <url copied earlier> > $ cd buildr > > Step six: add my repository as a remote by using the following command. > Feel free to repeat this step for any other repositories you wish to pull > from: > > $ git remote add daniel git://github.com/djspiewak/buildr.git > > Step seven: fetch the changes from my repository: > > $ git fetch daniel > > Step eight: create a new branch based on my `gae` branch and select it as > the current working branch: > > $ git branch gae daniel/gae > $ git checkout gae > > Step nine: hack, hack, hack, hack (you may find this cheatsheet helpful: > http://ktown.kde.org/~zrusin/git/git-cheat-sheet-medium.png<http://ktown.kde.org/%7Ezrusin/git/git-cheat-sheet-medium.png> > ) > Step ten: push your gae branch (including all of your commits) up to your > clone of the Buildr repository: > > $ git push origin gae > > (note: once you have run the above command, future changes can be pushed > simply by running `git push`) > > Step eleven: let me know that you've made some changes! I'll pull your > changes into my repository (merging with my local gae branch). > > Rinse and repeat from step seven, and eventually we'll get something put > together that is ready to push into the main Buildr repository. Once we're > ready, I'll merge our gae branch in with the trunk and commit our changes > using git-svn. It's easy! (actually, there's some legal releases which > have to take place somewhere in there, but we can worry about those later) > > If you have any questions, feel free to ask here on the mailing-list. We > like to encourage contribution as much as possible, which is the main > reason > we have Git clones in the first place. You are of course free to just send > us patch files (the best way to do this is by attaching them to a JIRA > issue), but Git is a lot easier once you get the hang of it. > > Daniel > > On Sun, Aug 16, 2009 at 1:51 PM, Shane Witbeck <[email protected] > >wrote: > > > 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 > >> > > > > > >> > > > > >> > > > >> > > >> > > > > >
