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/34feb3baa2bf6372e81fb91b176ac376d469e... https://github.com/rritoch/abcl/commit/fd0ecafc28b909a484436691dc7bf83b97875...
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.
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."