forgot to answer another point. Right now it's for posix (Linux) only. but that could change as the project progresses.
On Thu, Jan 31, 2019 at 11:51 AM Clebert Suconic <clebert.suco...@gmail.com> wrote: > > -- 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 >> > -- Clebert Suconic
