What about https://issues.apache.org/jira/browse/BUILDR-301 (Build completes successfully on configuration failures) ? Is it possible that this will be fixed in the next release?
Cheers, Martin On Wed, 2009-09-16 at 16:22 +0200, Antoine Toulme wrote: > Can we reactive this discussion ? > I note rjb issued a new release to support Snow Leopard. > http://rubyforge.org/forum/forum.php?forum_id=34590 > > If it's ok, I can try it out, see if all specs pass with it ? > > Then it would be time to consider doing a release, what do you think ? > > What more can I do to help with it ? > > Thanks, > > Antoine > > > On Thu, Aug 20, 2009 at 22:35, Daniel Spiewak <[email protected]> wrote: > > > I vote that we should defer the release until September. That'll give all > > of us more time to get our stuff in order. We also need to decide which of > > my forks and knives to try to get into 1.4.0 (I vote for documentation > > support). Whatever we choose, I just don't see us able to get a solid > > release ready in the next week given the current commitments of the core > > developers. > > > > Daniel > > > > On Thu, Aug 20, 2009 at 3:30 PM, Alex Boisvert <[email protected]> > > wrote: > > > > > Sorry devs, I won't be able to tackle the 1.4 release before I leave for > > > vacation. I haven't managed to tame my work pile and I don't think it > > would > > > be advisable to make a release and disappear the next day. (I'm going to > > > pretend they don't have Internet on the island where I'm going) > > > > > > Feel free to release during my absence... otherwise I'll be back to this > > > around Sept. 7th. > > > > > > alex > > > > > > > > > On Tue, Aug 4, 2009 at 8:26 PM, Daniel Spiewak <[email protected]> > > > wrote: > > > > > > > I agree: we should start thinking about a release in the near future. > > I > > > > also agree that we should probably call it 1.4.0 rather than 1.3.5, > > > > reflecting the fact that we have added some interesting new features > > > (shell > > > > support, cleanup and polish of Scala features, cobertura:check, etc). > > > > > > > > The most important step in getting us to 1.4.0 would be checking up on > > > our > > > > faithful specs and making sure that everything is passing (particularly > > > on > > > > JRuby, given the extensive monkey patching we did in that department). > > > It > > > > would also be very nice to spec out the shell support, at least a > > little > > > > bit. In that vein, the shell API needs to be reorganized *slightly* > > > before > > > > we make a release, bringing it more in line with the test and compiler > > > APIs > > > > (extend Rake::Task, etc). That's pretty minor though, and wouldn't > > break > > > > any of the existing providers. > > > > > > > > As for my pending silverware... :-) I've got two significant features > > > > that > > > > I would *really* like to bring into the core at some point, preferably > > > > sooner rather than later. Unfortunately, I have run out of time to > > > > actually > > > > see these through (at least in the near future). These two features: > > > > > > > > - Continuous compilation (branch: continuous-compilation) > > > > - A generic documentation framework (branch: doc-framework) > > > > > > > > Both of these can be found in my Git fork: git:// > > > > github.com/djspiewak/buildr.git Unfortunately, as is typical of my > > work > > > > on > > > > Buildr, neither of them have working specs. :-) I've tried to spec > > out > > > > continuous-compilation, but I ran into some serious difficulties with > > > > RSpec's mocking framework. Help here would be appreciated! > > > > > > > > Continuous compilation is actually a remarkably simple extension, only > > > > about > > > > 80 or so lines of pretty straightforward Ruby. The only thing it's > > > lacking > > > > right now (besides specs) is the ability to recursively monitor > > > > sub-projects. This would be very easy for someone else to add though, > > > just > > > > fiddle with lib/buildr/core/cc.rb and you should be golden. > > > > > > > > The really interesting change (I think) is the generic doc framework. > > > This > > > > attempts to address a glaring weakness in Buildr's multi-language > > > support: > > > > documentation generation. Right now, Buildr has very convenient > > support > > > > for > > > > Javadoc (through the javadoc task), but no support for Scaladoc, > > > VScaladoc > > > > or Groovydoc. My doc-framework branch removes the javadoc task (with > > > > deprecation) and replaces it with a more generic doc task. This task > > > > detects the relevant doc gen provider based on the project language, > > then > > > > uses it to generate documentation in the _(:target, :doc) directory. > > It > > > > also includes support for overriding the default doc gen provider (e.g. > > > use > > > > :vscaladoc instead of the default on a Scala project). This is missing > > > > specs, documentation and actual support for Groovydoc (should be a few > > > > minutes of work, especially for someone who knows the Groovydoc API). > > > > Unlike continuous-compilation or interactive-shell, the generic doc > > > > framework should be quite straightforward to spec out and even easier > > to > > > > document. > > > > > > > > If I had to choose between the two, I would really like to get the > > > > documentation framework into the core before we make a release. > > However, > > > > continuous compilation support is a lot closer to completion, so it > > might > > > > be > > > > wiser to focus on it. Alternatively, we could push back the release > > > still > > > > further and try to get them both in. This would give us even more of > > an > > > > excuse to call it "1.4.0", but it does of course mean a longer delay. > > > > > > > > The big problem I have right now is that I just don't have time to > > follow > > > > up > > > > with any of these pending tasks. I'll do what I can, but I doubt I'll > > be > > > > able to put as much into Buildr as I have been in recent months. > > > > > > > > Daniel > > > > > > > > On Tue, Aug 4, 2009 at 7:42 PM, Alex Boisvert <[email protected]> > > > > wrote: > > > > > > > > > Buildrs, > > > > > > > > > > Our last release was back in April... Given that we have plenty of > > > > > improvements and fixes to justify a release, I think we should > > mentally > > > > > prepare releasing before the end of August. I was thinking of > > > shooting > > > > > for > > > > > the 18-19th since I'll be away on vacation 2 weeks after the 22nd. > > > > What > > > > > do you think? > > > > > > > > > > On my list... I'll start reviewing outstanding issues and maybe > > tackle > > > a > > > > > few > > > > > easy ones. I've also been working on the Rake <-> Buildr tutorial > > > > which > > > > > should be ready by that time. > > > > > > > > > > Anything on your list? There's also the question of whether we want > > > to > > > > > release 1.3.5 or rather make it 1.4.0. I personally don't have a > > > strong > > > > > preference either way. I think 1.4.0 would be a nice prop for the > > > > > interactive shell support. And even more so if we can squeeze other > > > > things > > > > > from Daniel's ever-growing tray of forks and knives ;) > > > > > > > > > > alex > > > > > > > > > > > > > >
signature.asc
Description: This is a digitally signed message part
