You may be creating more and more scripts for your systems, which need to use the same functions.
You already mastered the ancient art of copy-paste, but you are not satisfied with the result.
You probably know lots of Perl modules that allow you to use their functions and you also want to create one.
However, you don't know how to create such a module.
Recommended Project Layout
In order to avoid problems with syntax validation (such as packages reported missing) and the debugger (such as skipped breakpoints), it is best to organize your project according to the conventions of the core Perl distribution:
Keep your own modules in dedicated subtrees of your project. For example, create a subdirectory lib as the root of the subtree containing all *.pm files. Note that you can have more than one such subtree. For example, you could also create test/lib to store modules that are only imported by test scripts.
Add the root directories of your subtrees to the @INC path (see the section called “Perl Include Path”). For example, add the entries lib and test/lib there.
Map package names to paths in the subtree (and vice versa). For example, store code for the package Foo::Bar in file lib/Foo/Bar.pm and ensure that lib/Foo/Baz.pm contains only package Foo::Baz.
Store your Perl scripts anywhere you like in the project. For example, in subdirectory bin or cgi-bin.
To import from a package, use it, rather than require it. For example, use Foo::Bar; rather than require '../lib/Foo/Bar.pm';The Multi Module Maven Release Plugin for Git
This plugin is an alternative to the maven-release-plugin which was created with the following principles:
It should be trivial to release modules from a multi-module plugin, and only those modules that have changes should be released
No commits should be made to a repo during a release
Maven conventions such as developing against SNAPSHOT versions should be retained
Git should not need to be installed on the system.
See the introductory blog post for more background.
The plugin works with the idea that a software module has two types of versions: the “business version” and the “build number”. The business version is used for semantic versioning, and may be something like “1.0”, “1.1.0”, etc. During development, the version in the pom is the business version with -SNAPSHOT appended. During a release, module version becomes business-version.build-number and this is what the repo is tagged with, and this is what the pom version becomes in the deployed artifact (however this version is not committed as a change to your pom).
This plugin automatically generates build numbers, starting from 0 and incrementing each time, by looking at previous releases in the Git history. Alternatively, you can use a number that increments on each release - like your CI server’s build number for example.
Differences with the maven-release-plugin
Only Git is supported
Each module released will have a separate tag with its artifact ID and version so that it is easy to see when a version of a module was released
A module is only released if there are changes to it
The release version of the pom is not committed back to the repository
Tests are run once by default (or optionally not at all)
Créer des modules pour le NAS, mais attention le lien vers la GPL a changer, utiliser celui ci : ftp://ftp.dlink.fr/GPL_Source_Codes/DNS-320_GPL/DNS-320_GPL_code_revA.tgz
wget ftp://ftp.dlink.fr/GPL_Source_Codes/DNS-320_GPL/DNS-320_GPL_code_revA.tgz
tar xf DNS-320_GPL_code_revA.tgz
cd dns320_GPL
tar xf dns320_GPL.tgz
cd dns320_GPL
wget http://wolf-u.li/u/275
Bon ben la compilation du module SQLlite3 dans php 5.3 et supérieur est cassé quand on utilise les librairies internes à PHP... :/
bouu je vais devoir recompiler mon module ffp... :/