-- If the library is intended as a holder for "any JNI needed by Artemis," then I don't see value in dis-associating it from Artemis. OTOH, if the library has functionality that could be useful to other projects, outside of Artemis, then I can see a value to breaking it away from the Artemis name and making it more reusable.
I thought about the possibility of dis-associating. .but you're right.. it's a bit more complicated... I wouldn't disassociate. >>>> I don't have a concern either way on that front. Although I am not sure why it helps to do so. This is a chicken / egg situation. Right now when we build the native layer, we have to commit binary file on the git repository. I'm intending to fix that part. And that makes it difficult to have a real build from source experience. I have had a few cases where users needed to rebuild it from scratch, and bumped into this native issue, which I'm trying to improve here. The native layer build wouldn't have any .so, and the .so would be part of the release. On Thu, Jan 31, 2019 at 12:36 AM Arthur Naseef <a...@amlinv.com> wrote: > JNI is a broad category - which really just means calling out from Java to > native O/S libraries. > > If the library is intended as a holder for "any JNI needed by Artemis," > then I don't see value in dis-associating it from Artemis. OTOH, if the > library has functionality that could be useful to other projects, outside > of Artemis, then I can see a value to breaking it away from the Artemis > name and making it more reusable. > > As for making it a separate repo with its own lifecycle, I don't have a > concern either way on that front. Although I am not sure why it helps to > do so. Well, one question comes to mind - isn't this library Linux, or > Posix, specific? Or, does it build on all systems that might be used to > build Artemis? > > Art > > > On Wed, Jan 30, 2019 at 9:52 PM Clebert Suconic <clebert.suco...@gmail.com > > > wrote: > > > Currently it’s used for JNi operations around storage. Mostly libido. > But > > I foresee being used for other cases where we may need JNI. > > > > On Wed, Jan 30, 2019 at 5:53 PM Arthur Naseef <a...@amlinv.com> wrote: > > > > > What is in the library? > > > > > > Art > > > > > > > > > On Wed, Jan 30, 2019 at 11:08 AM Clebert Suconic < > > > clebert.suco...@gmail.com> > > > wrote: > > > > > > > I thought Since the native project had open scope like I'm proposing, > > > > it would eventually be useful anywhere that needs a JNI library. > > > > > > > > But we can go with activemq-artemis-native. That's fine. > > > > > > > > On Wed, Jan 30, 2019 at 12:51 PM jgenender <jgenen...@apache.org> > > wrote: > > > > > > > > > > Hey Clebert, > > > > > > > > > > This is really cool stuff. But I don't like it being called > > > > ActiveMQ-native > > > > > because it will confuse people with ActiveMQ classic (which really > is > > > > > ActiveMQ for now) or that it would even work with ActiveMQ 5.x. I > > > would > > > > > recommend retaining the Artemis in the name, or > > > ActiveMQ-Artemis-native. > > > > > If/when Artemis becomes ActiveMQ, then that could certainly be an > > > option > > > > to > > > > > drop Artemis. But at this stage I think its too confusing. > > > > > > > > > > Jeff > > > > > > > > > > > > > > > > > > > > -- > > > > > Sent from: > > > > http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html > > > > > > > > > > > > > > > > -- > > > > Clebert Suconic > > > > > > > > > -- > > Clebert Suconic > > >
