I'm going to make a few tweaks as soon as I get the chance. In the meantime, the best thing to do is to test this extension on a practical project. Since you felt the need to write the :enhance task, I'm assuming you're working on something with GAE. How well do the other tasks work? Do they work at all? It's been a while since I played with it, and I didn't do much intensive testing at the time. :-)
Daniel On Tue, Aug 18, 2009 at 5:19 PM, Shane Witbeck <[email protected]>wrote: > After jumping through a few hoops, I updated my fork of gae.rb with the > enhance task. > > http://github.com/digitalsanctum/buildr/tree/gae > > -Shane > > > On Mon, Aug 17, 2009 at 10:59 PM, Daniel Spiewak <[email protected] > >wrote: > > > I just looked at your GitHub home page (at > > http://github.com/digitalsanctum). > > I can see in your feed that you created the Buildr project, but I can't > > navigate to it. Did you delete it? I suspect that this may be a case > > where > > GitHub got something stuck in its queue and is now refusing to allow > > anybody > > access. You may have to open a support issue with them (they usually get > > back to you within a few days). > > > > Daniel > > > > On Mon, Aug 17, 2009 at 8:52 PM, Shane Witbeck <[email protected] > > >wrote: > > > > > Daniel, > > > > > > All seemed to work fine except when I get to Step nine: > > > > > > jackal:buildr shane$ git push origin gae > > > Repository not found. If you've just created it, please try again in a > > few > > > seconds. > > > fatal: The remote end hung up unexpectedly > > > > > > I had to do some manual hacking of my ~/.gitconfig file to get this > far. > > > Here's what it looks like: > > > > > > [user] > > > name = Shane Witbeck > > > email = [email protected] > > > [github] > > > user = digitalsanctum > > > token = 4704be457cb04aba23816c6d364a265d > > > [remote "origin"] > > > url = [email protected]:digitalsanctum/dotfiles.git > > > > > > > > > Have any suggestions? > > > > > > Thanks, > > > -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> > <http://ktown.kde.org/%7Ezrusin/git/git-cheat-sheet-medium.png> > > <http://ktown.kde.org/%7Ezrusin/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 > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > >
