Have abcl.jar include java and lisp source code by default

[Mark Evenson]

c.f. <​https://github.com/armedbear/abcl/issues/6>

[Mark Evenson]

alan:

Adds about 1.3 MB on top of 10.5 MB (figures for my recent jars)
Means that you can always see the source with meta-.

If there's a need for a small abcl.jar, have that also be buildable, but then maybe get rid of other things too.

[Mark Evenson]

mark:

There is already an Ant target to package source, which I would like to reuse here if possible. The subtlety here is that we normalize the line endings depending on whether we are making jar, zip, or tar.gz archives, which is probably a mistake that I would correct.

Would it be possible to use a separate jar to view source, using logical pathnames?

There is a need for separate source artifacts for the org.abcl Maven packaging anyways, so I would rather reuse this work rather than "bloating" abcl.jar. Even though I accept that a ~15% increase in jar size is probably fine, I definitely wouldn't want to have different results for making abcl.jar ("does it include source?" would not be a question that could be answered without inspection of the contents of abcl.jar).

[Mark Evenson]

alan:

It is certainly possible. It's a matter of what the default should be. If there are two jars then some fraction of people will not include it in their lib even if they don't realize it might be useful to them. Given that jar size isn't a factor in the bulk of cases I think the default should be to make things more rather than less. If someone is worried about file size given today's situation my guess is they are more sophisticated and in a better position to choose a abcl-min.jar (call it that so there aren't different content abcl.jar). I'd even venture to say its worth including abcl-contrib.jar in abcl.jar, with perhaps a function that removes those files from the search path for those who know enough to say they don't need it.

As far as line endings go, in the lib jar it doesn't matter so much as access to source would typically be via emacs which won't care. There can still be a source zip for people who are acquiring it for the purposes of unpacking it into a file system.

"Bloat" used to be something in the days when I didn't have 17 apps in my Applications folder that are more than 500MB each (there are 65 with more than 100MB!)

[Mark Evenson]

mark:

I'm still thinking about which way to go here, but here are some intermediate thoughts:

"bloat" may still be an issue in certain hardware situations (Android, RPi-class devices, your watch) and an issue for network bandwidth, but I agree such an argument will get weaker with the passage of time.

Overall, I guess my main objection lies in my gut-level resistance to changing the meaning of the filenames 'abcl.jar', 'abcl-contrib.jar' and 'abcl-sources.jar'. These are published artifacts in the distributed Maven graph at this point which doesn't have a great mechanism other than the name and associated version for ascribing semantics.

The current way forward for me would be to retain publishing the current artifacts, but add one more "uber-jar" ("abcl-uber.jar") that would contain sources and could even theoretically include the Maven libraries, Ant, as well as JNA as long as the licensing is compatible. With such an über Jar, ABCL could unpack itself easily in a development environment mode (why not include Swank and Quicklisp while we are at it?).

I would make the build system customizable as to which components are added to this "abcl-uber.jar" which should make things flexible enough for anyone's needs.

To be researched: current standards on "Jar manifests", as this work is leading me to think that ABCL should be able to introspect jar contents to figure out what it contains (Lisp code, Java libraries) etc.

[Mark Evenson]

alan:

An "über" jar works for me, as long as "uber" isn't part of it's name. How about ablc-aio.jar (all in one)

[Mark Evenson]

Github pull request from Alan <​https://github.com/armedbear/abcl/pull/7>

[Mark Evenson]

I merged in Alan's work as <​http://abcl.org/trac/changeset/14907>, and then added the start <​http://abcl.org/trac/changeset/14908> of a mechanism to declare where to look in a Jar file for ASDF definitions using Jar manifests.

Additional work on something like ONEjar to package Maven itself in the aio jar awaits another day.