FWIW I support the idea of splitting the projects, both at the source
and distribution levels.
On Tue, Sep 9, 2008 at 5:31 AM, Erik Huelsmann <ehuels@...> wrote:
> On Mon, Sep 8, 2008 at 9:48 AM, Mark Evenson <evenson@...> wrote:
>> Erik Huelsmann wrote:
>>> And I forgot to mention: releases for both ABCL and J. (The sooner the
>>> better: any takers?)
>> Releases in what sense?
> Well, I was looking at what's currently there, for starters. My idea
> was to do with what we have available, building plans to improve it
> after we have some visible evidence of the fact that the project lives
> So, in this case that would mean creating abcl and j tar and zip files
> for source distribution. After we have the old-but-unreleased code
> out, we can take the following steps:
> - create a binary distritution for ABCL
> - split the j.jar file in an abcl.jar and a j.jar
> - create a binary release for J
> Then, when we finish all this, upon a release, we create 2 source
> releases (Windows [.zip] and Unix[.tar.gz]) and a binary release
> (which doesn't need localization!)
>> Pushing a binary from SVN up to common-lisp.net?
>> I can definitely help with the ABCL part of that kind
>> of release process, as I have ASDF definitions plus new code for
>> platform detection within ABCL (mainly generalizing the idea of
>> *platform* to work across more UNIX-like systems) for BUILD-ABCL and
> Looking at the above, I think it's even simpler than creating a binary
> distribution: we need to run the tests and create a source
> distribution, afaics.
>> What I am weak on is a) running this stuff under win32 and b) what a
>> functional J actually looks on, which is why creating reproducible tests
>> that we can meaningfully triage bug reports across will be very helpful
>> (running on a JVM can mean a greater platform variance than more
>> traditional software distribution mechanisms)
> You're waaayyyy ahead of me :-)
>> Some random thoughts on what release engineering for ABCL might involve:
>> 1. is J truly separable from ABCL? Let's prove it by creating a j.jar
>> that needs abcl.jar in its CLASSPATH to work. Getting this sort of
>> release engineering done early will help in the long run. And provides
>> the right kind of path
> I think making this split will simply amount to adjusting the
> build.xml file the right way; ie. introducing an abcl.jar file which
> will be created next to the j.jar file. Only 1 problem: I have no
> experience with the Ant build system (as a creator).
>> 1.1 With a j.jar, J becomes the "first-class" consumer of ABCL: we
>> support releasing it in its current state until someone shows up who has
>> a real interest in extending J in some manner. Getting tests that show
>> a given release of J is acceptable would help create a better release
> Absolutely! And I think we will need a release process defined.
>> 1.2 We create an easily extendable test suite for ABCL that includes
>> 1.2.1 The ANSI tests
>> 1.2.2 the stuff under src/org/armedbear/lisp/tests
>> 1.2.3 What we need to gain confidence that our fixes for ABCL are not
>> messing up things that we thought were working
>> This test suite becomes a consumer of ABCL as well, but is not included
>> in abcl.jar.
> That would be nice. However, I think the current tests/ directory is
> excluded upon j.jar creation.
>> 3. We start building releases with JDK-1.5 from Sun as the most common
>> JVM "platform" out there. I can do older releases with JDK-1.4 under
>> ia32-solaris-5.11 if neeeded, but this would be in a special binary.
>> Something like Retroweaver (??) could help "back porting" anything we
>> end up doing with Java 5 specific features like Annotations, but I could
>> use some help here because I haven't regularly used JDK-1.4 since 2005.
> Well, there's one problem with javac1.4, because I've introduced
> generics to silence compiler warnings about unchecked code: they are
> 1.5 level compatibility. Does your solaris 1.4 JDK support generics?
>> 4. We plan on skipping JDK-1.6 as a target platform, going directly for
>> the first widely deployed OpenJDK to implement JSR-292. This set of
>> target platforms currently contains only the Da Vinci VM by John Rose
>> et. at. at Sun.
> Having a MOP at all would be more of a priority to me than using the
> invokedynamic instruction, especially because that would bring ABCL on
> par with some of the other implementations out there. *Having* the
> functionality is required before you can work on the speed of the
> implementation :-) However, what's great here is that this is open
> source and everybody gets to scratch his/her itch, meaning that if
> this is your priority, that's perfectly fine (and I'll support it too,
>> 4.1 ABCL 1.0 would run on Java 5
>> 4.2 ABCL 2.0 would run on Java 7 (and redo the underlying Java class
>> structure to efficiently utilize JSR-292's invokedynamic)
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> armedbear-j-devel mailing list