Proposal to improve the loading of the abcl-contrib dependency.
rritoch at gmail.com
Mon Aug 3 15:18:42 UTC 2015
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 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.
On Sun, Aug 2, 2015 at 6:15 AM, Mark Evenson <evenson at 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
> > 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].
> 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.
> : 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."
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the armedbear-devel