Add a module to CPAN that wraps up all the MICR stuff that you want to provide. Have it use various other helper modules that are bundled up in the same distribution:

xxx::MICR
xxx::MICR::Helper1
xxx::MICR::Helper2
xxx::MICR::Helper3
[download]

and provide the script to drive it in a Samples directory which may include other related stuff.

CPAN does have a scripts repository, but the less said about that the better - it's very much a fourth class citizen compared to the module repository.

GrandFather, this is useful for set of perl modules/ a distro, with tests, etc.. the main focus are the modules and the functionality they provide.
Your suggestion in useful. With something like CGI::Application, this kind of thing is useful.

It makes sense and I've seen that done in distros.

I think your explanation falls really short of addressing my concerns- however. Maybe I didn't do a good job in explaining myself.

The scripts, helper data, config files, whatever.. these are not examples, these would be a good chunk of functional stuff. It's stuff that will be available system wide to all users, etc. They're production scripts/material.

And a lot of it is not .pm material.

The stuff really is more of a project- but the modules allow other programs/scripts/uis, to work with the same stuff.

Maybe I should separate these things further.

Actually I really did mean to imply that you provide all the ancillary material in conjunction with a main module. It would be nice if the CPAN scripts repository were organised and maintained in the same fashion as the modules repository - that would be the ideal answer. But it's not, and failing that I think that a good solution is to provide your complete project keyed to a primary module.

I don't think it matters that the scripts etc. are not examples. If they are useful to other people then CPAN is a good way to make them available and it is likely that people looking for the stuff you are working with will find it on CPAN by way of a well named module.

Don't separate them further. Tie them all together into a single distribution.

---

Perl reduces RSI - it saves typing

Reading this, I have the impression, that the MICR/OCR modules contribute a significant but not a major part to the overall applications functionality? I further assume that they make only a relatively small part of the projects total size (e.g. some kB MICR*.pm + some MB for bitmaps, configs, templates, etc.)?

If this is true, the application should deserve its own project site and the MICR module its slot at CPAN. It doesn't make sense that an overwhelmingly large part of the project deals with just demonstrating the functionality of a single module. That would also degrade your application to just a demo - which it doesn't seem to be. On the other side, most people downloading your module might not be interested in the very specific functionality, the application offers.

So the question is where to draw the line between module (CPAN) and application (project site)?
It is a litmus test for a modules usefulness, that it can demonstrate its capabilities with a relatively short amount of demo code. If you cannot come up with a small demo program, the module might not be fit for the given purpose, yet. The demo is not supposed to do something useful - it's aim is to educate. A potential demo candidate might be found among the CLI tools.
If bitmaps are part of the module, e.g. for calibration purpose, put them into the modules package, but make it as small as possible in order to focus on the very specific functionality the module promises to deliver. A link in the modules documentation can point to your projects site, where you can keep CLI tools and the web based application for those interested in more than the module or those who want to see the modules usage in a bigger application.

Splitting application and module(s) might have the additional advantage, that you can concentrate on the application and don't have to update the CPAN any time, you have added a new feature to your application which doesn't fit into a module. I would expect, that the application provides more opportunities for development (changes at a higher rate) than the module after it has stabilised. Although beta/preview-versions of the module could be made available at the project site first, increasing quality and stability of the module uploaded to CPAN. The application site comes handy too if you develop another application based on the same module or if you want to provide some megabytes of OCRs for demo- and test-purpose.

Just some thoughts, ...

You might want to look at how MIMEDefang does their distribution. They have recently been breaking usable parts out into generally useful modules and putting them on CPAN.

The files I know about were released by dfs and David O'Neill. It may not be exactly how you do it, but it is a successful large scale project that had some of the same problems to solve.

dfs is very nice, he may have be able to tell you why they chose to do things a certain way if you ask.

I've chosen to follow the example of Andy Lester's App::Ack. Assuming approval from modules@perl.org, my application will use the App::XXXXXX namespace. The cli goes in scripts and is just a wrapper around the main App::XXXXXX.pm.

Andy Lester seems to use his own server for the App::Ack website, Google Groups for the community mailing list (including developers), and Google Code for the Subversion repo for developers in addition to maintaining the release version of App::Ack on CPAN.

Since a check organizer can be used by nonprogrammers, I'd recommend setting up an external website and mailing list as a community hub, as opposed to relying on CPAN and RT.

Because the user community for my application will likely consist mainly of people who are unfamiliar with perl, this node discusses ways besides CPAN that a user will be able to get the application.

While my application doesn't have a web interface, if it did I'd include the cgi files somewhere in the CPAN distribution, along with instructions for setting them up.

(This message was updated several times.)