<div dir="ltr">Hi all,<br><div class="gmail_extra"><br><div class="gmail_quote">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><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><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><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><div><br></div>-- <br><div class="gmail_signature"><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>
</div></div>