<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On 8 Jun 2009, at 19:51, David Golden wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Mon, Jun 8, 2009 at 12:46 PM, Ovid<<a href="mailto:publiustemp-tapx@yahoo.com">publiustemp-tapx@yahoo.com</a>> wrote:<br><blockquote type="cite">What would it take for TH to be split into two distributions? One of those would reside in core and only contain core features. The other (Test::Harness::Extended?) would be where new features are developed.<br></blockquote><br>Are you sure this isn't a job for roles? ;-) (j/k)<br><br>On the serious side, Test::Harness has done a pretty good job of<br>breaking up functionality into separate modules -- the problem is that<br>it's damn hard to replace any one of those in practice given the way<br>testing is called from EU::MM or M::B. I recently added support for a<br>"HARNESS_SUBCLASS" environment variable so that TAP::Harness could<br>easily be replaced by TAP::Harness::Archive without re-writing<br>someone's build code.<br><br>That's a hack, but it's a symptom of the larger problem. If<br>Test::Harness were written to make it easy to swap in components, then<br>that could the module that remains core and everything fancy could be<br>Test::HarnessX::Foo, etc.</div></blockquote><div><br></div><div>Agreed.</div><div><br></div><div>That's one of the problems that's come up on the "Perl's not the only TAP source" thread... hopefully we've solved the main case where you want to add a new source (like an archive). That should reduce the cases where you'd want or need to sub-class at the level of TAP::Harness (or TAP::Parser), which is a step in the right direction. If there are other use cases, we should list them out, and find similar ways of dealing with them. If we need better hooks into M::B or EU::MM, then we should list those to.</div><div><br></div><div>For example, I still think the App::Prove plugin system needs some work (support plugin-defined cmdline params). But arguably App::Prove doesn't need to be in Core (ie: it wouldn't be used directly by build scripts), so not something we need to worry about here.</div><div><br></div><div>As for adding Test::Harness to Core, I think it makes sense, but only after we sort out the plugin / extension system. Otherwise we'll create a swath of backwards-compat pain that we've got to deal with for years to come.</div><div><br></div><div><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" style="font: normal normal normal 12px/normal Helvetica; ">+--</font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" style="font: normal normal normal 12px/normal Helvetica; "> Steve Purkis</font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br></div></div></div></div></div></div></div></div></body></html>