buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Boisvert" <boisv...@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:27:05 GMT
Make all of them separate gems?

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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message