Say that a later point we add a new library to support a new device or new native API.
I would prefer we still produce a new .SO for artemis. That is.. Artemis-Native-32.so and Artemis-Native-64.so. Just to make it illustrative lets say we want to support MagneticTapes on the Journal. The new JNI operations would be embedded as part of the same .so. On that case, you would have src/java/main/.... LibAIO.java /src/java/main/....LibMagneticType.java that will generate two .c and .h files src/java/c/.....LibMagnetic.c libMagnetic.h src/java/c/.....LibAIO.c libAIO.c and a single .so The cost to maintain the Cmake and its built it's somewhat high IMO. Bootstrapping a new project later on to allow the new API would require a lot more time and investment. As a matter of fact, I have plans for some APIs in a near future (that I don't want to bring to this discussion now, as I don't want to make any promises), but having them on a separate project would make time investment a bit higher, for no reason. On Wed, Jan 30, 2019 at 12:29 PM Francesco Nigro <nigro....@gmail.com> wrote: > > Re the naming: native would be a module for all the sub component sharing > native interfaces of any kind. I prefer that too even if, effectively ATM > we will have just libAIO on it... > > Il giorno mer 30 gen 2019 alle ore 18:18 Clebert Suconic < > clebert.suco...@gmail.com> ha scritto: > > > I would not like to make the libaio part of the name. A similar > > mistake happened on the Netty Project, when I tried to bring libaio > > into netty. Their native library was for epoll at the time only and > > that made things complicated at the time. They later made things more > > generic but I never got to bring libaio there again (I don't think it > > made sense for Netty). > > > > We may have only libaio now, but I can foresee adding more things in > > the future, like New APIs for future Storage.. future network.. > > dunno... I just like to keep the name open. > > > > If you don't like the name native that's fine.. but libaio is too > > restrictive. > > > > On Wed, Jan 30, 2019 at 12:15 PM michael.andre.pearce > > <michael.andre.pea...@me.com.invalid> wrote: > > > > > > Just on name front. I would call it activemq-libaio > > > Native is a bit too generic, it could mean support for epoll, kqueue or > > even cpp client also. > > > Re vote, i think rather than a vote for this specific sub project. We > > should decide on common guidelines for sub projects and rules for future, > > for me its better we agree and vote on policies to make clear rules. > > > E.g. > > > We could be voting for a policy such as > > > "a sub project is deemed a project that is supporting or adding to the > > activemq ecosystem, a sub project can be created without the need for vote, > > simply by the support of a single pmc member or two committers sponsoring. > > On creation a NOTICE should be sent to dev mailing lists" > > > In such guideline / rule got voted on then this would obviously would > > not need separate vote, as would have a pmc member sponsoring (yourself > > clebert) > > > > > > > > > Sent from my Samsung Galaxy smartphone. > > > -------- Original message --------From: Francesco Nigro < > > nigro....@gmail.com> Date: 30/01/2019 16:58 (GMT+00:00) To: > > dev@activemq.apache.org Subject: Re: [DISCUSS] ActiveMQ Artemis Native as > > a separated project > > > +100 for this one and I would be pleased to do it, maybe with the help of > > > both Clebert and Otavio (that's quite good with native stuff!) :) > > > Obviously Michael you know that you're more then welcome on it as well > > eh, > > > I'm just taking the initiative :D > > > > > > Il giorno mer 30 gen 2019 alle ore 17:51 michael.andre.pearce > > > <michael.andre.pea...@me.com.invalid> ha scritto: > > > > > > > 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 > > > > > > > > > > > > -- > > Clebert Suconic > > -- Clebert Suconic
