Looking at the code we found out that parts of it made no sense. Asbjørn provided me with a good example demonstrating the bug, so this was quickly translated to a test (BDKPHN-10) and the non-sense code and the issue could be addressed.

The release has been uploaded to PAUSE and should be available on CPAN.

Thanks to Asbjørn for reporting the bug.

jonasbn, Copenhagen

PS. this post was cross-posted from the project blog on Business::DK::Phonenumber

Task::Jenkins is a collection of distributions for continuous integration using Jenkins it installs a collection of distributions which have been identified as useful in utilizing Jenkins for continuous integration of Perl distributions, applications and code.

The key concept in the use of Jenkins for Perl is enabling the existing tool chain with minor adjustments.

The basic requirements are that you are using some sort of build system, basically you just need some way to initiate an execution of you test suite from a command line. The test suite is then expected to output to the console so the output from the test run can be inspected and the return value of the test run can be used to indicate whether the test run was a success or failure.

Using standard tool chain components like Test::Harness works out of the box.

For a tutorial on how to get started please see the wiki page on Continuous Integration with Perl.

The distribution is a Task based distribution, so it does not contain any code as such, but simply bundles existing distributions for easy handling. Currently Task::Jenkins contain:

- App::Prove

- Devel::Cover

- TAP::Formatter::JUnit

Suggestions, feedback, patches etc. most welcome,

jonasbn

PS. this post was cross-posted from the project blog on Task::Jenkins

The issue was labelled: BDKFI-20. The change can be inspected in Fisheye.

The distribution will be made available via CPAN and your local mirror shortly or you can go to MetaCPAN.

Thanks to my colleague Erik Johansen for the assistance and pointer to what the problem was.

jonasbn, Copenhagen

This post was cross-posted from: logicLAB.jira.com

I have created a Task implementation bundle listing my two own policies for now (I expect to add other policies used later on). This gives you the opportunity to download the policies by themselves if they look like something you would like to use or you can even bundle them yourself with other policies you make use of.

This packaging is an experiment and is not the recommended way and so it might change in the future, so let me know if you have any feedback on the packaging, both if you are using Perl::Critic::logicLAB or the actual policies directly.

The policies which have also just been released and currently listed in Perl::Critic::logicLAB are:

• Perl::Critic::Policy::logicLAB::ProhibitUseLib
• Perl::Critic::Policy::logicLAB::RequireVersionFormat

Both are simple policies, but hopefully useful.

All should be available on CPAN by now.

jonasbn, Copenhagen

Based on CPAN testers results I could see that after making the POD generation a part of the build, I need to move the requirement for Tie::IxHash to be asserted prior to the build. So the configuration phase should identify the requirement for Tie::IxHash.

The distribution is using Tie::IxHash to create the POD documentation as a part of the build process. This step is implemented as a step of it’s own, but it has been integrated with the build action, simply so the step is not forgotten.

My original idea was to have the list in Build.PL and the let the CONTENTS section, be auto-generated. So Bundle::JONASBN and Task::BeLike::JONASBN contain it’s own custom build system, based on a sub class of Module::Build. The build system (Module::Build::Bundle) read the requirements from Build.PL and inserts this in the CONTENTS section, alphabetized.
I attempted to let the build system create beautiful POD, instead of the standardized used in bundles. It took me several attempts to figure out that it was the reason my particular bundle was not working as expected.
Bundles require some special magic on the client side to parse the CONTENTS section, in this case primarily the CPAN client and the requirements for developing a bundle are quite special and IMHO error prone. It took me 4 releases to get it right, I was simply not grasping the magic part.
Adam Kennedy at some point recognized this weakness in the tool chain and introduced Task, a new much simpler approach. Task is based simply on writing up the requirements in the build file, whether you use Module::Build, ExtUtils::MakeMaker or Module::Install.
Tasks are easier to maintain and validate.
I was in that lucky position that I had put all my requirements in my Build.PL since release 0.01. So when I choose to migrate to a Task based approach it was just a matter of renaming packages etc.
Much of all my trouble was due to the fact that I had thought that the approach would be the approach used in Task. But AFAIK it is a combination of package name: Bundle:: and the CONTENTS section.
I have now migrated to the Task approach and reinstated the beautification of the POD and everything works well and looks nice, well apart from the little glitch with the order of assertions, but luckily Module::Build handles the META file generation and the fix was fairly simple.

After reading the documentation and doing some considering I decided to deprecate Bundle::JONASBN and then redo the same distribution as Task::BeLike::JONASBN.

The project is in the same repository and Bundle::JONASBN was refactored to support this and the project site was renamed also. Many of the pointers are still using the internally used project key BJONASBN.

The Task concept is fairly easy and being a supporter of KISS, I am thinking about using this concept for other things currently on the drawing board.

Kudos should go to Adam Kennedy for the Task contribution to CPAN, it is simply beautiful in all it’s simplicity.

Task::BeLike::JONASBN has been released to CPAN as version 1.00 making it a major release on the same code base.

Task::BeLike::JONASBN and Bundle::JONASBN will live in parallel for an amount of time, but Bundle::JONASBN will be removed from CPAN eventually and all future development will be centered around Task::BeLike::JONASBN.

Apart from the class addition, the release only addresses minor issues, like a failing test case reported by CPAN-testers. POD has been updated and the Build file has been adjusted.

The Changes file does not contain all the changes, it is lacking a serious update so please refer to the project change log for details.

Source code is available from: http://logicLAB.jira.com/svn/BDKCPR/

Project homepage: http://logiclab.jira.com/browse/BDKCPR/

Wiki: http://logiclab.jira.com/wiki/display/BDKCPR/Home

Feedback and patches more than welcome,

From the Changes file:

- Implemented work-around for RT #53909
https://rt.cpan.org/Ticket/Display.html?id=53909

The issue demonstrated here, which can be observed in perl versions newer
than 5.10.0 seems to be related to a issue mentioned here:

http://rt.perl.org/rt3/Public/Bug/Display.html?id=70171

RT #53909 is based on blead perl, in which also a fix has now been
implemented, but we still have issues with a lot of perl releases currently
out there, see:

http://matrix.cpantesters.org/?dist=Workflow+1.33

So this work-around seems to fix the issue, since I can no longer replicate
the error. The problem seem to be the clearing of a package scoped variable,
the array @observations in t/SomeObserver.pm

Release 0.03 implemented a new feature, supporting DanDomains authorization by IP, so it is not necessary to crawl the site and authenticate. So access directory to the source of exported data is possible with the correct configuration on the DanDomain side.

After new releases I always keep an keen eye on the test reports from CPAN testers and much to my surprise I got a failure report.

WWW-DanDomain-0.03:
- i386-freebsd / 5.10.1:
- FAIL http://www.cpantesters.org/cpan/report/6848267

It seemed as if the Makefile.PL was not parsed completely and only the first line in the requirements and configuration requirements sections where parsed.

The distribution is primarily based on Module::Build, so I overlooked this.

Using the CPAN-testers website I located the testers email address and mailed him. He was very responsive and he informed me that his smoke testing environment was configured to pick the Makefile.PL over Build.PL and my Makefile.PL only contained the two lines in the two sections I previously mentioned.

So I examined the culprit and he was right.

Confused over what the Makefile.PL I moved on the the Build.PL file, which I expected to generated the Makefile.PL and I could see that that particular feature was not configured.

So release 0.04 contains a fix to address this.

Thanks to CPAN Testers again, they help finding even the smallest of defects.