Emma and Cobertura getting to good for addon Re: svn commit: r700747 - /incubator/buildr/trunk/rakelib/rspec.rake

[Assaf Arkin <ar...@intalio.com>]

The reason I didn't include addon to begin with is that everything
there is (or was) stuff that fell out of lib: not as well maintained,
documented, tested or committed to.

I wasn't expecting it to have full or for that matter any test
coverage, but rather for some parts to mature and either move to lib,
or collected into separate gems (e.g. buildr-coverage).

Not sure if we should keep this policy, but if we do, let's move Emma
and Cobertura to lib.

Assaf


On Wed, Oct 1, 2008 at 5:14 AM,  <la...@apache.org> wrote:
> Author: lacton
> Date: Wed Oct  1 05:14:19 2008
> New Revision: 700747
>
> URL: http://svn.apache.org/viewvc?rev=700747&view=rev
> Log:
> Keep an eye on the test coverage of addons
>
> Modified:
>    incubator/buildr/trunk/rakelib/rspec.rake
>
> Modified: incubator/buildr/trunk/rakelib/rspec.rake
> URL: http://svn.apache.org/viewvc/incubator/buildr/trunk/rakelib/rspec.rake?rev=700747&r1=700746&r2=700747&view=diff
> ==============================================================================
> --- incubator/buildr/trunk/rakelib/rspec.rake (original)
> +++ incubator/buildr/trunk/rakelib/rspec.rake Wed Oct  1 05:14:19 2008
> @@ -46,7 +46,7 @@
>     task.spec_opts << '--colour' if $stdout.isatty
>     task.rcov = true
>     task.rcov_dir = 'reports/coverage'
> -    task.rcov_opts << '--exclude / --include-file ^lib --text-summary'
> +    task.rcov_opts << '--exclude / --include-file ^lib --include-file ^addon --text-summary'
>   end
>   file 'reports/coverage'=>'coverage'
>
>
>
>

Re: Emma and Cobertura getting to good for addon Re: svn commit: r700747 - /incubator/buildr/trunk/rakelib/rspec.rake

[lacton <la...@users.sourceforge.net>]

Assaf,

On Mon, Oct 6, 2008 at 2:07 AM, Assaf Arkin <ar...@intalio.com> wrote:
> On Sun, Oct 5, 2008 at 12:32 PM, lacton <la...@users.sourceforge.net> wrote:
>> Moving Emma and Cobertura to lib is fine with me.
>>
>> One thing I'd like to keep is that the extension should be loaded only
>> if required by the user or the buildfile.  Right now, the way the
>> Emma/Cobertura extensions work is to add the test coverage tool to the
>> test task's dependencies and to add the instrumentation step before
>> testing.  I don't want to penalize users that don't want to measure
>> their test coverage.
>>
>> My understanding is that, currently, everything in lib is required
>> during startup.  Should we add an 'optional import' directory in lib?
>
> You have to require 'buildr/groovy' explicitly, but you're compensated
> for your effort by having the Groovy compiler handle both Java and
> Groovy source files.  So it's not without precedent to have stuff in
> lib that's loaded explicitly.

Thank you for reminding me of this fact.

In that case, I'd like to move the two test coverage tools to lib/ as
soon as the 1.3.3 release is done.

If later we find that lib/ is too bloated for our taste, we can always
use the separate gem tactic at that time.

Lacton

Re: Emma and Cobertura getting to good for addon Re: svn commit: r700747 - /incubator/buildr/trunk/rakelib/rspec.rake

[Assaf Arkin <ar...@intalio.com>]

On Sun, Oct 5, 2008 at 12:32 PM, lacton <la...@users.sourceforge.net> wrote:
> On Thu, Oct 2, 2008 at 12:15 AM, Assaf Arkin <ar...@intalio.com> wrote:
>> The reason I didn't include addon to begin with is that everything
>> there is (or was) stuff that fell out of lib: not as well maintained,
>> documented, tested or committed to.
>>
>> I wasn't expecting it to have full or for that matter any test
>> coverage, but rather for some parts to mature and either move to lib,
>> or collected into separate gems (e.g. buildr-coverage).
>>
>> Not sure if we should keep this policy, but if we do, let's move Emma
>> and Cobertura to lib.
>
> Moving Emma and Cobertura to lib is fine with me.
>
> One thing I'd like to keep is that the extension should be loaded only
> if required by the user or the buildfile.  Right now, the way the
> Emma/Cobertura extensions work is to add the test coverage tool to the
> test task's dependencies and to add the instrumentation step before
> testing.  I don't want to penalize users that don't want to measure
> their test coverage.
>
> My understanding is that, currently, everything in lib is required
> during startup.  Should we add an 'optional import' directory in lib?

You have to require 'buildr/groovy' explicitly, but you're compensated
for your effort by having the Groovy compiler handle both Java and
Groovy source files.  So it's not without precedent to have stuff in
lib that's loaded explicitly.

Assaf

>
> Lacton
>

Re: Emma and Cobertura getting to good for addon Re: svn commit: r700747 - /incubator/buildr/trunk/rakelib/rspec.rake

[Assaf Arkin <ar...@intalio.com>]

On Sun, Oct 5, 2008 at 7:19 PM, Alex Boisvert <bo...@intalio.com> wrote:
> I'm volunteering to convert some of them to gems.   Maintenance should be
> split over the community.
>
> I was thinking of defining a common infrastructure (Github, release scripts,
> wiki documentation and index) which can then be reused by others as template
> and guidelines for new plugins.

Until that community steps forward and takes care of maintaining 11
gems, I would suggest something simpler, and more practical.  First,
decide what to do with each of these 11 components:

antlr
cobertura
emma
hibernate
javacc
jdepend
jetty
jibx
nailgun
openjpa
xmlbeans

Those that we want to see in lib, we know what to do with.  The rest,
we either discard, or find a different way to publish them, I would
suggest a single catch-all buildr-addon gem.  One gem is significantly
less pain to maintain than 11.

Assaf

>
> alex
>
>
> On Mon, Oct 6, 2008 at 10:46 AM, Assaf Arkin <ar...@intalio.com> wrote:
>
>> On Sun, Oct 5, 2008 at 6:27 PM, Alex Boisvert <bo...@intalio.com>
>> wrote:
>> > Make all of them separate gems?
>>
>> Are you volunteering to maintain 11 separate gems?
>>
>> Assaf
>>
>> >
>> > alex
>> >
>> > On Mon, Oct 6, 2008 at 10:14 AM, Assaf Arkin <ar...@intalio.com> wrote:
>> >
>> >> On Sun, Oct 5, 2008 at 5:21 PM, Alex Boisvert <bo...@intalio.com>
>> >> wrote:
>> >> > I'm fine either way.  We just have to pick one way, migrate the
>> current
>> >> > plugins and document how to do it.
>> >>
>> >> We have 11 components in addons, so we just need to decide what to do
>> >> with each one.
>> >>
>> >> antlr
>> >> cobertura
>> >> emma
>> >> hibernate
>> >> javacc
>> >> jdepend
>> >> jetty
>> >> jibx
>> >> nailgun
>> >> openjpa
>> >> xmlbeans
>> >>
>> >> Assaf
>> >>
>> >> >
>> >> > I can help but I don't have much experience with Gem packaging yet.
>>  If
>> >> > there's a good example I can learn from, I can probably port the other
>> >> > plugins and write some doc.
>> >> >
>> >> > alex
>> >> >
>> >> >
>> >> > On Mon, Oct 6, 2008 at 9:12 AM, Assaf Arkin <ar...@intalio.com>
>> wrote:
>> >> >
>> >> >> On Sun, Oct 5, 2008 at 4:51 PM, Alex Boisvert <bo...@intalio.com>
>> >> >> wrote:
>> >> >> > How about "addon" for optional plugins that have tests and are
>> >> officially
>> >> >> > supported and "experimental" for the rest?
>> >> >>
>> >> >> As of 1.3.0 we have a wonderful mechanism that allows you to package
>> >> >> extensions as separate Gems and require them in your buildfile, so
>> >> >> there's no need for either addon or experimental.  If it's too
>> >> >> specific to be part of core, spin it off to its own sub-project and
>> >> >> gem.
>> >> >>
>> >> >> Assaf
>> >> >>
>> >> >> >
>> >> >> > alex
>> >> >> >
>> >> >> >
>> >> >> > On Mon, Oct 6, 2008 at 4:32 AM, lacton <
>> lacton@users.sourceforge.net>
>> >> >> wrote:
>> >> >> >
>> >> >> >> On Thu, Oct 2, 2008 at 12:15 AM, Assaf Arkin <ar...@intalio.com>
>> >> wrote:
>> >> >> >> > The reason I didn't include addon to begin with is that
>> everything
>> >> >> >> > there is (or was) stuff that fell out of lib: not as well
>> >> maintained,
>> >> >> >> > documented, tested or committed to.
>> >> >> >> >
>> >> >> >> > I wasn't expecting it to have full or for that matter any test
>> >> >> >> > coverage, but rather for some parts to mature and either move to
>> >> lib,
>> >> >> >> > or collected into separate gems (e.g. buildr-coverage).
>> >> >> >> >
>> >> >> >> > Not sure if we should keep this policy, but if we do, let's move
>> >> Emma
>> >> >> >> > and Cobertura to lib.
>> >> >> >>
>> >> >> >> Moving Emma and Cobertura to lib is fine with me.
>> >> >> >>
>> >> >> >> One thing I'd like to keep is that the extension should be loaded
>> >> only
>> >> >> >> if required by the user or the buildfile.  Right now, the way the
>> >> >> >> Emma/Cobertura extensions work is to add the test coverage tool to
>> >> the
>> >> >> >> test task's dependencies and to add the instrumentation step
>> before
>> >> >> >> testing.  I don't want to penalize users that don't want to
>> measure
>> >> >> >> their test coverage.
>> >> >> >>
>> >> >> >> My understanding is that, currently, everything in lib is required
>> >> >> >> during startup.  Should we add an 'optional import' directory in
>> lib?
>> >> >> >>
>> >> >> >> Lacton
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >
>> >>
>> >
>>
>

Re: Emma and Cobertura getting to good for addon Re: svn commit: r700747 - /incubator/buildr/trunk/rakelib/rspec.rake

[Alex Boisvert <bo...@intalio.com>]

I'm volunteering to convert some of them to gems.   Maintenance should be
split over the community.

I was thinking of defining a common infrastructure (Github, release scripts,
wiki documentation and index) which can then be reused by others as template
and guidelines for new plugins.

alex


On Mon, Oct 6, 2008 at 10:46 AM, Assaf Arkin <ar...@intalio.com> wrote:

> On Sun, Oct 5, 2008 at 6:27 PM, Alex Boisvert <bo...@intalio.com>
> wrote:
> > Make all of them separate gems?
>
> Are you volunteering to maintain 11 separate gems?
>
> Assaf
>
> >
> > alex
> >
> > On Mon, Oct 6, 2008 at 10:14 AM, Assaf Arkin <ar...@intalio.com> wrote:
> >
> >> On Sun, Oct 5, 2008 at 5:21 PM, Alex Boisvert <bo...@intalio.com>
> >> wrote:
> >> > I'm fine either way.  We just have to pick one way, migrate the
> current
> >> > plugins and document how to do it.
> >>
> >> We have 11 components in addons, so we just need to decide what to do
> >> with each one.
> >>
> >> antlr
> >> cobertura
> >> emma
> >> hibernate
> >> javacc
> >> jdepend
> >> jetty
> >> jibx
> >> nailgun
> >> openjpa
> >> xmlbeans
> >>
> >> Assaf
> >>
> >> >
> >> > I can help but I don't have much experience with Gem packaging yet.
>  If
> >> > there's a good example I can learn from, I can probably port the other
> >> > plugins and write some doc.
> >> >
> >> > alex
> >> >
> >> >
> >> > On Mon, Oct 6, 2008 at 9:12 AM, Assaf Arkin <ar...@intalio.com>
> wrote:
> >> >
> >> >> On Sun, Oct 5, 2008 at 4:51 PM, Alex Boisvert <bo...@intalio.com>
> >> >> wrote:
> >> >> > How about "addon" for optional plugins that have tests and are
> >> officially
> >> >> > supported and "experimental" for the rest?
> >> >>
> >> >> As of 1.3.0 we have a wonderful mechanism that allows you to package
> >> >> extensions as separate Gems and require them in your buildfile, so
> >> >> there's no need for either addon or experimental.  If it's too
> >> >> specific to be part of core, spin it off to its own sub-project and
> >> >> gem.
> >> >>
> >> >> Assaf
> >> >>
> >> >> >
> >> >> > alex
> >> >> >
> >> >> >
> >> >> > On Mon, Oct 6, 2008 at 4:32 AM, lacton <
> lacton@users.sourceforge.net>
> >> >> wrote:
> >> >> >
> >> >> >> On Thu, Oct 2, 2008 at 12:15 AM, Assaf Arkin <ar...@intalio.com>
> >> wrote:
> >> >> >> > The reason I didn't include addon to begin with is that
> everything
> >> >> >> > there is (or was) stuff that fell out of lib: not as well
> >> maintained,
> >> >> >> > documented, tested or committed to.
> >> >> >> >
> >> >> >> > I wasn't expecting it to have full or for that matter any test
> >> >> >> > coverage, but rather for some parts to mature and either move to
> >> lib,
> >> >> >> > or collected into separate gems (e.g. buildr-coverage).
> >> >> >> >
> >> >> >> > Not sure if we should keep this policy, but if we do, let's move
> >> Emma
> >> >> >> > and Cobertura to lib.
> >> >> >>
> >> >> >> Moving Emma and Cobertura to lib is fine with me.
> >> >> >>
> >> >> >> One thing I'd like to keep is that the extension should be loaded
> >> only
> >> >> >> if required by the user or the buildfile.  Right now, the way the
> >> >> >> Emma/Cobertura extensions work is to add the test coverage tool to
> >> the
> >> >> >> test task's dependencies and to add the instrumentation step
> before
> >> >> >> testing.  I don't want to penalize users that don't want to
> measure
> >> >> >> their test coverage.
> >> >> >>
> >> >> >> My understanding is that, currently, everything in lib is required
> >> >> >> during startup.  Should we add an 'optional import' directory in
> lib?
> >> >> >>
> >> >> >> Lacton
> >> >> >>
> >> >> >
> >> >>
> >> >
> >>
> >
>

Re: Emma and Cobertura getting to good for addon Re: svn commit: r700747 - /incubator/buildr/trunk/rakelib/rspec.rake

[Assaf Arkin <ar...@intalio.com>]

On Sun, Oct 5, 2008 at 6:27 PM, Alex Boisvert <bo...@intalio.com> wrote:
> Make all of them separate gems?

Are you volunteering to maintain 11 separate gems?

Assaf

>
> alex
>
> On Mon, Oct 6, 2008 at 10:14 AM, Assaf Arkin <ar...@intalio.com> wrote:
>
>> On Sun, Oct 5, 2008 at 5:21 PM, Alex Boisvert <bo...@intalio.com>
>> wrote:
>> > I'm fine either way.  We just have to pick one way, migrate the current
>> > plugins and document how to do it.
>>
>> We have 11 components in addons, so we just need to decide what to do
>> with each one.
>>
>> antlr
>> cobertura
>> emma
>> hibernate
>> javacc
>> jdepend
>> jetty
>> jibx
>> nailgun
>> openjpa
>> xmlbeans
>>
>> Assaf
>>
>> >
>> > I can help but I don't have much experience with Gem packaging yet.  If
>> > there's a good example I can learn from, I can probably port the other
>> > plugins and write some doc.
>> >
>> > alex
>> >
>> >
>> > On Mon, Oct 6, 2008 at 9:12 AM, Assaf Arkin <ar...@intalio.com> wrote:
>> >
>> >> On Sun, Oct 5, 2008 at 4:51 PM, Alex Boisvert <bo...@intalio.com>
>> >> wrote:
>> >> > How about "addon" for optional plugins that have tests and are
>> officially
>> >> > supported and "experimental" for the rest?
>> >>
>> >> As of 1.3.0 we have a wonderful mechanism that allows you to package
>> >> extensions as separate Gems and require them in your buildfile, so
>> >> there's no need for either addon or experimental.  If it's too
>> >> specific to be part of core, spin it off to its own sub-project and
>> >> gem.
>> >>
>> >> Assaf
>> >>
>> >> >
>> >> > alex
>> >> >
>> >> >
>> >> > On Mon, Oct 6, 2008 at 4:32 AM, lacton <la...@users.sourceforge.net>
>> >> wrote:
>> >> >
>> >> >> On Thu, Oct 2, 2008 at 12:15 AM, Assaf Arkin <ar...@intalio.com>
>> wrote:
>> >> >> > The reason I didn't include addon to begin with is that everything
>> >> >> > there is (or was) stuff that fell out of lib: not as well
>> maintained,
>> >> >> > documented, tested or committed to.
>> >> >> >
>> >> >> > I wasn't expecting it to have full or for that matter any test
>> >> >> > coverage, but rather for some parts to mature and either move to
>> lib,
>> >> >> > or collected into separate gems (e.g. buildr-coverage).
>> >> >> >
>> >> >> > Not sure if we should keep this policy, but if we do, let's move
>> Emma
>> >> >> > and Cobertura to lib.
>> >> >>
>> >> >> Moving Emma and Cobertura to lib is fine with me.
>> >> >>
>> >> >> One thing I'd like to keep is that the extension should be loaded
>> only
>> >> >> if required by the user or the buildfile.  Right now, the way the
>> >> >> Emma/Cobertura extensions work is to add the test coverage tool to
>> the
>> >> >> test task's dependencies and to add the instrumentation step before
>> >> >> testing.  I don't want to penalize users that don't want to measure
>> >> >> their test coverage.
>> >> >>
>> >> >> My understanding is that, currently, everything in lib is required
>> >> >> during startup.  Should we add an 'optional import' directory in lib?
>> >> >>
>> >> >> Lacton
>> >> >>
>> >> >
>> >>
>> >
>>
>

Re: Emma and Cobertura getting to good for addon Re: svn commit: r700747 - /incubator/buildr/trunk/rakelib/rspec.rake

[Alex Boisvert <bo...@intalio.com>]

Make all of them separate gems?

alex

On Mon, Oct 6, 2008 at 10:14 AM, Assaf Arkin <ar...@intalio.com> wrote:

> On Sun, Oct 5, 2008 at 5:21 PM, Alex Boisvert <bo...@intalio.com>
> wrote:
> > I'm fine either way.  We just have to pick one way, migrate the current
> > plugins and document how to do it.
>
> We have 11 components in addons, so we just need to decide what to do
> with each one.
>
> antlr
> cobertura
> emma
> hibernate
> javacc
> jdepend
> jetty
> jibx
> nailgun
> openjpa
> xmlbeans
>
> Assaf
>
> >
> > I can help but I don't have much experience with Gem packaging yet.  If
> > there's a good example I can learn from, I can probably port the other
> > plugins and write some doc.
> >
> > alex
> >
> >
> > On Mon, Oct 6, 2008 at 9:12 AM, Assaf Arkin <ar...@intalio.com> wrote:
> >
> >> On Sun, Oct 5, 2008 at 4:51 PM, Alex Boisvert <bo...@intalio.com>
> >> wrote:
> >> > How about "addon" for optional plugins that have tests and are
> officially
> >> > supported and "experimental" for the rest?
> >>
> >> As of 1.3.0 we have a wonderful mechanism that allows you to package
> >> extensions as separate Gems and require them in your buildfile, so
> >> there's no need for either addon or experimental.  If it's too
> >> specific to be part of core, spin it off to its own sub-project and
> >> gem.
> >>
> >> Assaf
> >>
> >> >
> >> > alex
> >> >
> >> >
> >> > On Mon, Oct 6, 2008 at 4:32 AM, lacton <la...@users.sourceforge.net>
> >> wrote:
> >> >
> >> >> On Thu, Oct 2, 2008 at 12:15 AM, Assaf Arkin <ar...@intalio.com>
> wrote:
> >> >> > The reason I didn't include addon to begin with is that everything
> >> >> > there is (or was) stuff that fell out of lib: not as well
> maintained,
> >> >> > documented, tested or committed to.
> >> >> >
> >> >> > I wasn't expecting it to have full or for that matter any test
> >> >> > coverage, but rather for some parts to mature and either move to
> lib,
> >> >> > or collected into separate gems (e.g. buildr-coverage).
> >> >> >
> >> >> > Not sure if we should keep this policy, but if we do, let's move
> Emma
> >> >> > and Cobertura to lib.
> >> >>
> >> >> Moving Emma and Cobertura to lib is fine with me.
> >> >>
> >> >> One thing I'd like to keep is that the extension should be loaded
> only
> >> >> if required by the user or the buildfile.  Right now, the way the
> >> >> Emma/Cobertura extensions work is to add the test coverage tool to
> the
> >> >> test task's dependencies and to add the instrumentation step before
> >> >> testing.  I don't want to penalize users that don't want to measure
> >> >> their test coverage.
> >> >>
> >> >> My understanding is that, currently, everything in lib is required
> >> >> during startup.  Should we add an 'optional import' directory in lib?
> >> >>
> >> >> Lacton
> >> >>
> >> >
> >>
> >
>

Re: Emma and Cobertura getting to good for addon Re: svn commit: r700747 - /incubator/buildr/trunk/rakelib/rspec.rake

[Assaf Arkin <ar...@intalio.com>]

On Sun, Oct 5, 2008 at 5:21 PM, Alex Boisvert <bo...@intalio.com> wrote:
> I'm fine either way.  We just have to pick one way, migrate the current
> plugins and document how to do it.

We have 11 components in addons, so we just need to decide what to do
with each one.

antlr
cobertura
emma
hibernate
javacc
jdepend
jetty
jibx
nailgun
openjpa
xmlbeans

Assaf

>
> I can help but I don't have much experience with Gem packaging yet.  If
> there's a good example I can learn from, I can probably port the other
> plugins and write some doc.
>
> alex
>
>
> On Mon, Oct 6, 2008 at 9:12 AM, Assaf Arkin <ar...@intalio.com> wrote:
>
>> On Sun, Oct 5, 2008 at 4:51 PM, Alex Boisvert <bo...@intalio.com>
>> wrote:
>> > How about "addon" for optional plugins that have tests and are officially
>> > supported and "experimental" for the rest?
>>
>> As of 1.3.0 we have a wonderful mechanism that allows you to package
>> extensions as separate Gems and require them in your buildfile, so
>> there's no need for either addon or experimental.  If it's too
>> specific to be part of core, spin it off to its own sub-project and
>> gem.
>>
>> Assaf
>>
>> >
>> > alex
>> >
>> >
>> > On Mon, Oct 6, 2008 at 4:32 AM, lacton <la...@users.sourceforge.net>
>> wrote:
>> >
>> >> On Thu, Oct 2, 2008 at 12:15 AM, Assaf Arkin <ar...@intalio.com> wrote:
>> >> > The reason I didn't include addon to begin with is that everything
>> >> > there is (or was) stuff that fell out of lib: not as well maintained,
>> >> > documented, tested or committed to.
>> >> >
>> >> > I wasn't expecting it to have full or for that matter any test
>> >> > coverage, but rather for some parts to mature and either move to lib,
>> >> > or collected into separate gems (e.g. buildr-coverage).
>> >> >
>> >> > Not sure if we should keep this policy, but if we do, let's move Emma
>> >> > and Cobertura to lib.
>> >>
>> >> Moving Emma and Cobertura to lib is fine with me.
>> >>
>> >> One thing I'd like to keep is that the extension should be loaded only
>> >> if required by the user or the buildfile.  Right now, the way the
>> >> Emma/Cobertura extensions work is to add the test coverage tool to the
>> >> test task's dependencies and to add the instrumentation step before
>> >> testing.  I don't want to penalize users that don't want to measure
>> >> their test coverage.
>> >>
>> >> My understanding is that, currently, everything in lib is required
>> >> during startup.  Should we add an 'optional import' directory in lib?
>> >>
>> >> Lacton
>> >>
>> >
>>
>

Re: Emma and Cobertura getting to good for addon Re: svn commit: r700747 - /incubator/buildr/trunk/rakelib/rspec.rake

[Alex Boisvert <bo...@intalio.com>]

I'm fine either way.  We just have to pick one way, migrate the current
plugins and document how to do it.

I can help but I don't have much experience with Gem packaging yet.  If
there's a good example I can learn from, I can probably port the other
plugins and write some doc.

alex


On Mon, Oct 6, 2008 at 9:12 AM, Assaf Arkin <ar...@intalio.com> wrote:

> On Sun, Oct 5, 2008 at 4:51 PM, Alex Boisvert <bo...@intalio.com>
> wrote:
> > How about "addon" for optional plugins that have tests and are officially
> > supported and "experimental" for the rest?
>
> As of 1.3.0 we have a wonderful mechanism that allows you to package
> extensions as separate Gems and require them in your buildfile, so
> there's no need for either addon or experimental.  If it's too
> specific to be part of core, spin it off to its own sub-project and
> gem.
>
> Assaf
>
> >
> > alex
> >
> >
> > On Mon, Oct 6, 2008 at 4:32 AM, lacton <la...@users.sourceforge.net>
> wrote:
> >
> >> On Thu, Oct 2, 2008 at 12:15 AM, Assaf Arkin <ar...@intalio.com> wrote:
> >> > The reason I didn't include addon to begin with is that everything
> >> > there is (or was) stuff that fell out of lib: not as well maintained,
> >> > documented, tested or committed to.
> >> >
> >> > I wasn't expecting it to have full or for that matter any test
> >> > coverage, but rather for some parts to mature and either move to lib,
> >> > or collected into separate gems (e.g. buildr-coverage).
> >> >
> >> > Not sure if we should keep this policy, but if we do, let's move Emma
> >> > and Cobertura to lib.
> >>
> >> Moving Emma and Cobertura to lib is fine with me.
> >>
> >> One thing I'd like to keep is that the extension should be loaded only
> >> if required by the user or the buildfile.  Right now, the way the
> >> Emma/Cobertura extensions work is to add the test coverage tool to the
> >> test task's dependencies and to add the instrumentation step before
> >> testing.  I don't want to penalize users that don't want to measure
> >> their test coverage.
> >>
> >> My understanding is that, currently, everything in lib is required
> >> during startup.  Should we add an 'optional import' directory in lib?
> >>
> >> Lacton
> >>
> >
>

Re: Emma and Cobertura getting to good for addon Re: svn commit: r700747 - /incubator/buildr/trunk/rakelib/rspec.rake

[Assaf Arkin <ar...@intalio.com>]

On Sun, Oct 5, 2008 at 4:51 PM, Alex Boisvert <bo...@intalio.com> wrote:
> How about "addon" for optional plugins that have tests and are officially
> supported and "experimental" for the rest?

As of 1.3.0 we have a wonderful mechanism that allows you to package
extensions as separate Gems and require them in your buildfile, so
there's no need for either addon or experimental.  If it's too
specific to be part of core, spin it off to its own sub-project and
gem.

Assaf

>
> alex
>
>
> On Mon, Oct 6, 2008 at 4:32 AM, lacton <la...@users.sourceforge.net> wrote:
>
>> On Thu, Oct 2, 2008 at 12:15 AM, Assaf Arkin <ar...@intalio.com> wrote:
>> > The reason I didn't include addon to begin with is that everything
>> > there is (or was) stuff that fell out of lib: not as well maintained,
>> > documented, tested or committed to.
>> >
>> > I wasn't expecting it to have full or for that matter any test
>> > coverage, but rather for some parts to mature and either move to lib,
>> > or collected into separate gems (e.g. buildr-coverage).
>> >
>> > Not sure if we should keep this policy, but if we do, let's move Emma
>> > and Cobertura to lib.
>>
>> Moving Emma and Cobertura to lib is fine with me.
>>
>> One thing I'd like to keep is that the extension should be loaded only
>> if required by the user or the buildfile.  Right now, the way the
>> Emma/Cobertura extensions work is to add the test coverage tool to the
>> test task's dependencies and to add the instrumentation step before
>> testing.  I don't want to penalize users that don't want to measure
>> their test coverage.
>>
>> My understanding is that, currently, everything in lib is required
>> during startup.  Should we add an 'optional import' directory in lib?
>>
>> Lacton
>>
>

Re: Emma and Cobertura getting to good for addon Re: svn commit: r700747 - /incubator/buildr/trunk/rakelib/rspec.rake

[Alex Boisvert <bo...@intalio.com>]

How about "addon" for optional plugins that have tests and are officially
supported and "experimental" for the rest?

alex


On Mon, Oct 6, 2008 at 4:32 AM, lacton <la...@users.sourceforge.net> wrote:

> On Thu, Oct 2, 2008 at 12:15 AM, Assaf Arkin <ar...@intalio.com> wrote:
> > The reason I didn't include addon to begin with is that everything
> > there is (or was) stuff that fell out of lib: not as well maintained,
> > documented, tested or committed to.
> >
> > I wasn't expecting it to have full or for that matter any test
> > coverage, but rather for some parts to mature and either move to lib,
> > or collected into separate gems (e.g. buildr-coverage).
> >
> > Not sure if we should keep this policy, but if we do, let's move Emma
> > and Cobertura to lib.
>
> Moving Emma and Cobertura to lib is fine with me.
>
> One thing I'd like to keep is that the extension should be loaded only
> if required by the user or the buildfile.  Right now, the way the
> Emma/Cobertura extensions work is to add the test coverage tool to the
> test task's dependencies and to add the instrumentation step before
> testing.  I don't want to penalize users that don't want to measure
> their test coverage.
>
> My understanding is that, currently, everything in lib is required
> during startup.  Should we add an 'optional import' directory in lib?
>
> Lacton
>

Re: Emma and Cobertura getting to good for addon Re: svn commit: r700747 - /incubator/buildr/trunk/rakelib/rspec.rake

[lacton <la...@users.sourceforge.net>]

On Thu, Oct 2, 2008 at 12:15 AM, Assaf Arkin <ar...@intalio.com> wrote:
> The reason I didn't include addon to begin with is that everything
> there is (or was) stuff that fell out of lib: not as well maintained,
> documented, tested or committed to.
>
> I wasn't expecting it to have full or for that matter any test
> coverage, but rather for some parts to mature and either move to lib,
> or collected into separate gems (e.g. buildr-coverage).
>
> Not sure if we should keep this policy, but if we do, let's move Emma
> and Cobertura to lib.

Moving Emma and Cobertura to lib is fine with me.

One thing I'd like to keep is that the extension should be loaded only
if required by the user or the buildfile.  Right now, the way the
Emma/Cobertura extensions work is to add the test coverage tool to the
test task's dependencies and to add the instrumentation step before
testing.  I don't want to penalize users that don't want to measure
their test coverage.

My understanding is that, currently, everything in lib is required
during startup.  Should we add an 'optional import' directory in lib?

Lacton