You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@buildr.apache.org by Antoine Toulme <an...@lunar-ocean.com> on 2009/09/16 16:22:33 UTC
Re: Discuss: Buildr 1.3.5
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 <dj...@gmail.com> 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 <bo...@intalio.com>
> 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 <dj...@gmail.com>
> > 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 <bo...@intalio.com>
> > > 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
> > > >
> > >
> >
>
Re: Discuss: Buildr 1.3.5
Posted by Alex Boisvert <al...@gmail.com>.
On Wed, Sep 16, 2009 at 9:10 AM, Rhett Sutphin <rh...@detailedbalance.net>wrote:
> Perhaps it would be possible to do a 1.3.5 release with various bugfixes
> which have already been committed (including OS X 10.6 support), then
> consider which new features should be merged in for 1.4.0?
>
This would be my preference as well.
I'm happy to start the release process with what we have (+ a few more bug
fixes) so we get a release by next week.
alex
Re: Discuss: Buildr 1.3.5
Posted by Rhett Sutphin <rh...@detailedbalance.net>.
Hi,
On Sep 16, 2009, at 9:34 AM, Daniel Spiewak wrote:
> Alex seems to be the official release-maker at this point. I would
> be in
> favor of a 1.3.5 release (actually, I think we had settled on
> jumping to
> 1.4). Before we do though, I think we should probably decide which
> (if any)
> of my unmerged branches (listed earlier in the thread) should be
> pulled into
> the trunk/.
Perhaps it would be possible to do a 1.3.5 release with various
bugfixes which have already been committed (including OS X 10.6
support), then consider which new features should be merged in for
1.4.0?
Rhett
> Obviously, I would love to see *everything* I do automatically
> make it into the mainline, so someone else needs to make this
> decision. :-)
>
> Daniel
>
> On Wed, Sep 16, 2009 at 9:31 AM, Rhett Sutphin <rhett@detailedbalance.net
> >wrote:
>
>> Hi all,
>>
>> On Sep 16, 2009, at 9:22 AM, 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 ?
>>>
>>
>> I believe Assaf's already updated trunk with the new version of rjb.
>>
>>
>> http://markmail.org/search/?q=buildr%20snow%20leopard#query:buildr
>> %20snow%20leopard+page:1+mid:cux73pnn5qr5vxi3+state:results
>>
>> Then it would be time to consider doing a release, what do you
>> think ?
>>>
>>> What more can I do to help with it ?
>>>
>>
>> It would be nice to have an officially-released Snow Leopard-
>> compatible
>> buildr 1.3.5. I'd also like to offer any assistance I can.
>>
>> Thanks,
>> Rhett
>>
>>
>>
>>
>>> Thanks,
>>>
>>> Antoine
>>>
>>>
>>> On Thu, Aug 20, 2009 at 22:35, Daniel Spiewak <dj...@gmail.com>
>>> 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 <boisvert@intalio.com
>>>> >
>>>> 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 <djspiewak@gmail.com
>>>>> >
>>>>> 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 <boisvert@intalio.com
>>>>>> >
>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
Re: Discuss: Buildr 1.3.5
Posted by Daniel Spiewak <dj...@gmail.com>.
Alex seems to be the official release-maker at this point. I would be in
favor of a 1.3.5 release (actually, I think we had settled on jumping to
1.4). Before we do though, I think we should probably decide which (if any)
of my unmerged branches (listed earlier in the thread) should be pulled into
the trunk/. Obviously, I would love to see *everything* I do automatically
make it into the mainline, so someone else needs to make this decision. :-)
Daniel
On Wed, Sep 16, 2009 at 9:31 AM, Rhett Sutphin <rh...@detailedbalance.net>wrote:
> Hi all,
>
> On Sep 16, 2009, at 9:22 AM, 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 ?
>>
>
> I believe Assaf's already updated trunk with the new version of rjb.
>
>
> http://markmail.org/search/?q=buildr%20snow%20leopard#query:buildr%20snow%20leopard+page:1+mid:cux73pnn5qr5vxi3+state:results
>
> Then it would be time to consider doing a release, what do you think ?
>>
>> What more can I do to help with it ?
>>
>
> It would be nice to have an officially-released Snow Leopard-compatible
> buildr 1.3.5. I'd also like to offer any assistance I can.
>
> Thanks,
> Rhett
>
>
>
>
>> Thanks,
>>
>> Antoine
>>
>>
>> On Thu, Aug 20, 2009 at 22:35, Daniel Spiewak <dj...@gmail.com>
>> 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 <bo...@intalio.com>
>>> 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 <dj...@gmail.com>
>>>> 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 <bo...@intalio.com>
>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
Re: Discuss: Buildr 1.3.5
Posted by Antoine Toulme <an...@lunar-ocean.com>.
On Wed, Sep 16, 2009 at 17:51, Antoine Toulme <an...@lunar-ocean.com>wrote:
>
>
> On Wed, Sep 16, 2009 at 16:31, Rhett Sutphin <rh...@detailedbalance.net>wrote:
>
>> Hi all,
>>
>> On Sep 16, 2009, at 9:22 AM, 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 ?
>>>
>>
>> I believe Assaf's already updated trunk with the new version of rjb.
>>
> He updated to 1.1.8, 1.1.9 got out since. Not sure of the difference.
>
Sorry for the noise, I was wrong. I missed the commit in the feed.
Thanks,
Antoine
>
>>
>> http://markmail.org/search/?q=buildr%20snow%20leopard#query:buildr%20snow%20leopard+page:1+mid:cux73pnn5qr5vxi3+state:results
>>
>> Then it would be time to consider doing a release, what do you think ?
>>>
>>> What more can I do to help with it ?
>>>
>>
>> It would be nice to have an officially-released Snow Leopard-compatible
>> buildr 1.3.5. I'd also like to offer any assistance I can.
>>
>> Thanks,
>> Rhett
>>
>>
>>
>>
>>> Thanks,
>>>
>>> Antoine
>>>
>>>
>>> On Thu, Aug 20, 2009 at 22:35, Daniel Spiewak <dj...@gmail.com>
>>> 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 <bo...@intalio.com>
>>>> 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 <dj...@gmail.com>
>>>>> 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 <bo...@intalio.com>
>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>
Re: Discuss: Buildr 1.3.5
Posted by Antoine Toulme <an...@lunar-ocean.com>.
On Wed, Sep 16, 2009 at 16:31, Rhett Sutphin <rh...@detailedbalance.net>wrote:
> Hi all,
>
> On Sep 16, 2009, at 9:22 AM, 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 ?
>>
>
> I believe Assaf's already updated trunk with the new version of rjb.
>
He updated to 1.1.8, 1.1.9 got out since. Not sure of the difference.
>
>
> http://markmail.org/search/?q=buildr%20snow%20leopard#query:buildr%20snow%20leopard+page:1+mid:cux73pnn5qr5vxi3+state:results
>
> Then it would be time to consider doing a release, what do you think ?
>>
>> What more can I do to help with it ?
>>
>
> It would be nice to have an officially-released Snow Leopard-compatible
> buildr 1.3.5. I'd also like to offer any assistance I can.
>
> Thanks,
> Rhett
>
>
>
>
>> Thanks,
>>
>> Antoine
>>
>>
>> On Thu, Aug 20, 2009 at 22:35, Daniel Spiewak <dj...@gmail.com>
>> 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 <bo...@intalio.com>
>>> 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 <dj...@gmail.com>
>>>> 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 <bo...@intalio.com>
>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
Re: Discuss: Buildr 1.3.5
Posted by Rhett Sutphin <rh...@detailedbalance.net>.
Hi all,
On Sep 16, 2009, at 9:22 AM, 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 ?
I believe Assaf's already updated trunk with the new version of rjb.
http://markmail.org/search/?q=buildr%20snow%20leopard#query:buildr%20snow%20leopard+page:1+mid:cux73pnn5qr5vxi3+state:results
> Then it would be time to consider doing a release, what do you think ?
>
> What more can I do to help with it ?
It would be nice to have an officially-released Snow Leopard-
compatible buildr 1.3.5. I'd also like to offer any assistance I can.
Thanks,
Rhett
>
> Thanks,
>
> Antoine
>
>
> On Thu, Aug 20, 2009 at 22:35, Daniel Spiewak <dj...@gmail.com>
> 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 <bo...@intalio.com>
>> 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 <dj...@gmail.com>
>>> 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
>>>> <bo...@intalio.com>
>>>> 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
>>>>>
>>>>
>>>
>>
Re: Discuss: Buildr 1.3.5
Posted by Rhett Sutphin <rh...@detailedbalance.net>.
Hi Alex,
On Sep 18, 2009, at 2:17 PM, Alex Boisvert wrote:
> Alright, I've cleaned up our bug list for 1.3.5 -- I moved out non-
> trivial
> issues without patches back to 'Unscheduled' and fixed/applied
> patches for
> the others.
>
> Now is a good time to shout if you have any issue you want to see
> fixed in
> 1.3.5 and you have some willingness to help resolving it in the
> coming days.
I ran my most complex build on the current trunk yesterday and it
worked well. I ran into one new issue (BUILDR-320), but it was easy
to work around and I don't think it should block the release.
Rhett
>
> And if I've missed any issue with patch attached, kindly send me the
> Jira
> URL and I'll see to it.
>
> cheers,
> alex
Re: Discuss: Buildr 1.3.5
Posted by Alex Boisvert <al...@gmail.com>.
Alright, I've cleaned up our bug list for 1.3.5 -- I moved out non-trivial
issues without patches back to 'Unscheduled' and fixed/applied patches for
the others.
Now is a good time to shout if you have any issue you want to see fixed in
1.3.5 and you have some willingness to help resolving it in the coming days.
And if I've missed any issue with patch attached, kindly send me the Jira
URL and I'll see to it.
cheers,
alex
Re: Discuss: Buildr 1.3.5
Posted by Martin Grotzke <ma...@javakaffee.de>.
Great, thx! :)
Cheers,
Martin
On Wed, 2009-09-16 at 10:19 -0700, Alex Boisvert wrote:
> I'll put it on top of my list.
>
> alex
>
> On Wed, Sep 16, 2009 at 9:30 AM, Martin Grotzke <
> martin.grotzke@javakaffee.de> wrote:
>
> > 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
> >
Re: Discuss: Buildr 1.3.5
Posted by Alex Boisvert <al...@gmail.com>.
Actually, issues with patches get priority on my list... I'll apply it as
soon as Github maintenance is over.
alex
On Wed, Sep 16, 2009 at 10:29 AM, Alexis Midon <al...@gmail.com>wrote:
> right on top of https://issues.apache.org/jira/browse/BUILDR-313 ? ;)
>
> On Wed, Sep 16, 2009 at 10:19 AM, Alex Boisvert <alex.boisvert@gmail.com
> >wrote:
>
> > I'll put it on top of my list.
> >
> > alex
> >
> > On Wed, Sep 16, 2009 at 9:30 AM, Martin Grotzke <
> > martin.grotzke@javakaffee.de> wrote:
> >
> > > 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
> > >
> >
>
Re: Discuss: Buildr 1.3.5
Posted by Alexis Midon <al...@gmail.com>.
right on top of https://issues.apache.org/jira/browse/BUILDR-313 ? ;)
On Wed, Sep 16, 2009 at 10:19 AM, Alex Boisvert <al...@gmail.com>wrote:
> I'll put it on top of my list.
>
> alex
>
> On Wed, Sep 16, 2009 at 9:30 AM, Martin Grotzke <
> martin.grotzke@javakaffee.de> wrote:
>
> > 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
> >
>
Re: Discuss: Buildr 1.3.5
Posted by Alex Boisvert <al...@gmail.com>.
I'll put it on top of my list.
alex
On Wed, Sep 16, 2009 at 9:30 AM, Martin Grotzke <
martin.grotzke@javakaffee.de> wrote:
> 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
>
Re: Discuss: Buildr 1.3.5
Posted by Martin Grotzke <ma...@javakaffee.de>.
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 <dj...@gmail.com> 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 <bo...@intalio.com>
> > 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 <dj...@gmail.com>
> > > 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 <bo...@intalio.com>
> > > > 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
> > > > >
> > > >
> > >
> >