[armedbear-devel] Maven & ABCL

[Mark Evenson]

On 2/9/11 9:36 PM, Alessio Stalla wrote:
> On Fri, Feb 4, 2011 at 12:48 PM, Alessio Stalla<alessiostalla at gmail.com>  wrote:
>> when I understand better how the whole [Maven] release process works, I'll
>> report here with more information.
>
> Ok, so I experimented a bit with Maven and the free Sonatype
> repositories. To do a release, you need to produce the jar,
> sources-jar, and javadoc-jar of your project, and sign them with a gpg
> key. You then have to publish them to the repository; doing it (i.e.
> signing + publishing) with Maven is probably the easiest thing,
> although there's a way to do it with Ant too (but you have to have
> additional Maven Ant tasks installed on your system).

[…]

I know that Maven can use Ant tasks, so the easiest way forward might be 
to have Ant continue to build while Maven packages it.   Maven has the 
reputation of strong—i.e. inflexible–ideas about directory layouts that 
may prove to make this task difficult.

If we use Ant to package, I would like to continue to have the main 
build.xml file not have external Ant dependencies to enable the ABCL 
source distribution to be easily built without any additional downloads 
(other than Ant).  A possible way to implement this would be to have an 
additional file, say 'maven-build.xml', that includes the main 
'build.xml' while requiring the Maven Ant tasks.

>
> As far as I can tell, no special format is *required* for the sources
> and javadoc jars, although the ones generated by Maven of course have
> a precise format: basically the packed src directory for sources, and
> the packed doc root directory for javadocs (you can see an example
> here:<https://oss.sonatype.org/content/repositories/releases/com/googlecode/ehcache-spring-annotations/ehcache-spring-annotations/1.1.2/>.
> ABCL doesn't have many javadocs, and anyway those are certainly not
> the main part of the documentation; but the javadoc jar is required
> and, if it follows the convention, it can be automatically picked up
> by Eclipse when you add ABCL as a Maven dependency.

At least this would put some pressure on us to add some more javadoc 
strings.  A reasonable summary of the org.armedbear.lisp package 
pointing to the Wiki and mailing list might be a decent start.

>
> Morale: this is not terribly complicated, and it would make ABCL
> available through another distribution channel. OTOH, I can't hide the
> fact that - besides my own personal convenience for my shared project
> - probably no-one is using ABCL in Maven projects right now, and
> having ABCL released through Maven would complicate its release
> process, not much for technical reasons but for organizational ones
> (e.g. who keeps ABCL's GPG key? How is it managed?).

Currently Erik maintains the GPG key we currently use for signing.  Does 
anyone have a model by which we could somehow share it?   It might be 
nice to start "rotating" the responsibility for the releases among the 
four core committers to help take some work off of Erik's plate.

> So, if you accept Maven release to be an official step in ABCL's
> release process, that would be great for me and I could of course help
> in setting it up, solving issues etc. Else, if you're ok with it, I
> can publish ABCL on Sonatype's repo on my own, without making it part
> of our official release policy; that means less hassle for ABCL, but
> more risk of stale Maven releases and other problems caused by having
> the release depend on a single person (of course I'll take the release
> seriously, but still, depending on a single individual is always
> problematic). The third option is NOT to release ABCL with Maven at
> all: if you think that it would hurt ABCL, either by complicating the
> release process too much, or by having too high a risk of out-of-date
> releases out in the wild, I will accept that.

As much as I loathe Maven, it is certainly a contemporary commonly-used 
feature of the Java ecosystem, so I in favor of eventually make it part 
of our official release, but in measured increments.  As steps forward, 
I would propose that we work on an acceptable mechanism to Mavenize ABCL 
releases, put it in trunk, and have Alessio make a release of the 
current ABCL via Sonatype.  Then, we can work on making that a part of 
the official release.

As for supporting even more of the Java ecosystem, I would 
parenthetically add there are two more potential ways to broaden our 
reach that I can think of that are lying dormant around my various 
filesystems.  One would be including Eclipse project information in the 
trunk, sharing most of the build instructions with Ant.  The second 
would be including OSGi packaging information in our jar which I worked 
with Alan as part of the URI PATHNAME work to implement.  My time is 
very constrained to move these along, especially with testing as 
Eclipse/Equinox are not in my daily toolbox, but if someone has an 
ability to test either, I can package up my current diffs for 
distribution via email.

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."