<div dir="ltr"><div><div><div><div>Erik,<br><br></div> 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.<br><br></div>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.<br><br></div>Best Regards,<br></div>  Ralph Ritoch<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 26, 2015 at 3:28 PM, Erik Huelsmann <span dir="ltr"><<a href="mailto:ehuels@gmail.com" target="_blank">ehuels@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Aug 25, 2015 at 6:07 PM, Ralph Ritoch <span dir="ltr"><<a href="mailto:rritoch@gmail.com" target="_blank">rritoch@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Anton & Blake,<br><br></div>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.<br></div></div></div></blockquote><div><br></div></span><div>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.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>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.<br></div></div></div></blockquote><div><br></div></span><div>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.</div></div><span class=""><div><br></div>-- <br><div><div dir="ltr">Bye,<div><br></div><div>Erik.</div><div><br></div><div><a href="http://efficito.com/" target="_blank">http://efficito.com</a> -- Hosted accounting and ERP.</div><div>Robust and Flexible. No vendor lock-in.</div></div></div>
</span></div></div>
</blockquote></div><br></div>