Tbh, i see nothing wrong with making it a mini sub project. If anything having some sub projects is a good thing. Would the supporting java code be moved also? And would we look to make the interfaces more generic? Im keen if we separate something thats currently tighly embedded in artemis, we make sure it is much more re-usable (e.g. even example alternative uses). On that note, i think there are other bits that could be split out, a bit like what occured in activemq5. E.g. spring integration, protocol manager, other extensions And should welcome this a little more with newer extensions or features that enhance activemq but not core broker.
Sent from my Samsung Galaxy smartphone. -------- Original message --------From: Clebert Suconic <clebert.suco...@gmail.com> Date: 30/01/2019 16:31 (GMT+00:00) To: dev@activemq.apache.org Subject: [DISCUSS] ActiveMQ Artemis Native as a separated project One of the modules of ActiveMQ Artemis is the Native Layer: https://github.com/apache/activemq-artemis/tree/056cee4183a048028c0a5417304eb89a540e1316/artemis-native We currently hold all JNI Calls (pretty much libaio ATM). It is stable and the release cycle is very long. Maybe one or two changes an year with the current scope. This may become different if we expand the scope of JNI operations supported by the broker). I would like to make it a separate git repository from ActiveMQ Artemis, with its own releasy cycle. (we would even be able to remove the currently .so that are currently checked in on artemis). It is the sensitive thing to do. I don't think it as a separate project, just as a separate repository with its own release cycle to make things easier. I would like to name it ActiveMQ-Native, dropping the word Artemis, as it would be used for any further JNI operations needed for any other Java Projects part of ActiveMQ Artemis. We currently only have libaio, but I would keep the door open for other JNI operations we may need. I was wondering if anyone have any other ideas around it. Also: Would we need a vote to proceed on such change after we reach a consensus on what to do here? -- Clebert Suconic
