Proposal to improve the loading of the abcl-contrib dependency.

[Ralph Ritoch]

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 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
> 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."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20150803/6dae0a14/attachment.html>