All conformance ansi-test's passed

[Ralph Ritoch]

Erik,

 I have a very specific set of features that I'm trying to produce which
don't in any way change the language itself. The end goal is to be able to
use ABCL for enterprise applications, such as those that would run using
technologies such as Apache Camel, Apache Tomcat, Apache Servicemix, and
the Spring framework. I don't intend to allow politics to stand in the way
of achieving these capabilities.  As for the dual-build system, removing
ant scripts isn't a high priority but is something I'm willing to consider
once the primary objectives are reached.  I am still very far from
achieving the primary objectives.  No matter what fate this fork has, it is
going to break backwards compatibility from the perspective of Java and if
this does merge back than it should merge back at a version 2.0 of ABCL.
There are also some core issues that I'm wrestling with such as what Java
version to bind to.  I would very much like to bind to Java 8, as I am now
doing, but Android doesn't yet support Java 8 so I am strongly considering
binding to Java 7 if I achieve the set goals before Android has support for
Java 8.  For complete Interoperability with enterprise applications I will
also need to change the compilation system to minimally support Java 7 and
add features to facilitate the generation of annotations. Spring,
Hibernate, JPA, and many other enterprise technologies make extensive use
of annotations. While annotations would be a nice feature to support, I
have a long way to go before I understand the compilation system enough to
upgrade it.

As for renaming the branch, I simply don't like the name "armed bear".  It
is a marketing issue. Does anyone actually believe IBM, Oracle, or
Microsoft would be open to tagging their systems with "Powered by armed
bear", I highly doubt it. "Powered by jrelisp" is neutral without no
sociopolitical ties and something a fortune 500 company could use without
concern for the impact it may have on their PR.

Best Regards,
  Ralph Ritoch

On Wed, Aug 26, 2015 at 3:28 PM, Erik Huelsmann <ehuels at gmail.com> wrote:

> Hi all,
>
> On Tue, Aug 25, 2015 at 6:07 PM, Ralph Ritoch <rritoch at gmail.com> wrote:
>
>> Anton & Blake,
>>
>> One example feature that I hope to support is OSGI. Direct support for
>> OSGI will likely cause a significant performance loss. That is why I'm
>> going to do a quick optimization of the entire system before I start
>> working on the new features. I believe OSGI is scheduled to be included in
>> Java 9, along with some new packaging facilities which I also hope to
>> support when I can find adequate documentation on the subject. These are
>> all features that belong in a fork because they can and probably will have
>> a negative impact on the performance of applications that don't need those
>> features. I hope to make these features pluggable eventually, but hard
>> coding them initially is much easier.
>>
>
> If the intent is to migrate things back to the original project in due
> time, the open source name for such an effort would be "a remote branch",
> not a fork. If you are not aware of this difference, you could start naming
> your repository "a branch". If you *are* aware of the difference (and I
> think you are, because you already were looking for a different name for
> your project, judging by the IRC communication), then I can only say it's a
> pity that you didn't have the patience to go through the process that's
> customary in open source to get your patches accepted. As an illustration
> of what I mean there: my first Mercurial patch was accepted yesterday. My
> initial submission was in May or June. Due to time constraints on my side
> *and* requirements from theirs, this process simply can take long and
> becomes more smooth over time.
>
> Using ant instead of maven is also a limitation I'm not willing to accept.
>> Most of the people I've talked to think I should skip maven and go directly
>> to a gradle build system. Since gradle can utilize maven, maven is adequate
>> for most development needs at this point.
>>
>
> Just for the record I'm taking this to the mailing list, because most of
> this took place on the mailing list: the project asked to migrate *all*
> current functionalities to Maven, if you want to deprecate the Ant build,
> not *just* the ones that are needed to make the ABCL upload into the Maven
> repository. Our hesitation to accept the Maven based build lies in the fact
> that we have had two build systems in the past. Out of experience, we can
> say "It doesn't work". So, claiming we don't want to move forward is simply
> wrong. We want to do it in a way that doesn't kill half the project's
> infrastructure. I'm sure people understand that, if presented this way.
>
> --
> Bye,
>
> Erik.
>
> http://efficito.com -- Hosted accounting and ERP.
> Robust and Flexible. No vendor lock-in.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20150827/fe6e712c/attachment.html>