Mark,

   I don't know if you are planning on coding the features that are being speculated but I have implemented this feature per the original specs. In addition to adding the version file I also moved some things around to facilitate resource filtering to fill in the version number on the version file. This replacement doesn't happen with ant but the lack of replacement doesn't break the ant build either. There are two commits which produce this feature.

https://github.com/rritoch/abcl/commit/34feb3baa2bf6372e81fb91b176ac376d469e48f
https://github.com/rritoch/abcl/commit/fd0ecafc28b909a484436691dc7bf83b97875f5c

This repairs the bug where the abcl-contrib package isn't being detected in single-jar applications. I have tested it and it is fully functional.

Best Regards,

  Ralph Ritoch

On Sun, Aug 2, 2015 at 6:15 AM, Mark Evenson <evenson@panix.com> wrote:

On 2015/8/1 19:30, Ralph Ritoch wrote:
[…]

> I wasn't aware that ABCL already has an
> extensibility system for the lifecycle, such as
> SYS:*MODULE-PROVIDER-FUNCTIONS*. If that can be used to override the
> default places to search for the abcl-contrib packages, than great. I
> didn't notice it in the code I was looking at.  The core problem that needs
> to be solved is making a reasonable deployment system for distributed
> single-jar (uberjar) applications.

[…]

An additional mechanism for modifying ABCL behavior at startup lies in
the ability to [add arbitrary code to the contents of system.lisp][1].
One could use this to install an additional hook to
SYS:*MODULE-PROVIDER-FUNCTIONS* which would be able to satisfy the
(REQUIRE :abcl-contrib) by referring to PATHNAMEs within the current
jar.  Thus, one could boot an überjar without recourse to anything
additional in ABCL.

[1]: http://abcl.org/trac/browser/trunk/abcl/abcl.properties.in#L13


--
"A screaming comes across the sky.  It has happened before, but there

is nothing to compare to it now."