[armedbear-devel] Maven & ABCL

[Alessio Stalla]

On Thu, Feb 10, 2011 at 7:56 AM, Mark Evenson <evenson at panix.com> wrote:
> 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.

Wait - Maven (by default) requires a certain directory structure if
you use it to build your project; but I'm not proposing that, it would
be a daunting task with no foreseeable benefits. I'm just proposing to
use Maven to "deploy" (i.e. copy to the repository) our already-made
releases. You can do it with Ant + Maven tasks too, but imho it's
simpler with Maven alone (which amounts to something like mvn
gpg:sign-and-deploy-file /path/to/abcl.jar /path/to/pom.xml repo-url,
same for sources and javadoc jars).

> 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.

That's certainly a possibility.

>>
>> 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.

Agreed.

>> 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.

Well, if that's already managed somehow, it's ok. I didn't want to
complicate the process with additional requirements.

>> 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.

Technically to "mavenize" ABCL releases, we need to generate the
javadoc and sources jars. All the rest (signing and deploying to the
repository) is done by Maven or Ant + Maven tasks; you can't generate
the signed files, commit them, and upload them separately, as far as I
know.

> 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.

I use Eclipse, but I don't know anything about OSGi. If you have in
mind specific tests I could do, please tell :)

Bye,
Alessio