buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: Emma and Cobertura getting to good for addon Re: svn commit: r700747 - /incubator/buildr/trunk/rakelib/rspec.rake
Date Mon, 06 Oct 2008 01:46:47 GMT
On Sun, Oct 5, 2008 at 6:27 PM, Alex Boisvert <boisvert@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 <arkin@intalio.com> wrote:
>
>> On Sun, Oct 5, 2008 at 5:21 PM, Alex Boisvert <boisvert@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 <arkin@intalio.com> wrote:
>> >
>> >> On Sun, Oct 5, 2008 at 4:51 PM, Alex Boisvert <boisvert@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 <arkin@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
>> >> >>
>> >> >
>> >>
>> >
>>
>

Mime
View raw message