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 02:19:07 GMT
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 <arkin@intalio.com> wrote:

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