On Thu, Feb 10, 2011 at 7:56 AM, Mark Evenson evenson@panix.com wrote:
On 2/9/11 9:36 PM, Alessio Stalla wrote:
On Fri, Feb 4, 2011 at 12:48 PM, Alessio Stallaalessiostalla@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