You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Christopher Shannon <ch...@gmail.com> on 2019/02/01 12:37:25 UTC
Re: [DISCUSS] ActiveMQ Artemis Native as a separated project
It makes sense to me to have a separate release cycle for the JNI parts. I
think lazy consensus is fine here and as long no one objects you can just
go ahead and create it without a formal vote.
On Thu, Jan 31, 2019 at 3:51 PM Clebert Suconic <cl...@gmail.com>
wrote:
> yep, so far the best name is ActiveMQ-Artemis-native
>
>
> I don't think this is a big deal and I don't intend to create a vote
> for this.. as this is regular business. We are creating a separate
> repository for the native part, not a project!
>
> Let me know If you anyone think I'm wrong and this needs a vote please.
>
> On Thu, Jan 31, 2019 at 1:59 PM Arthur Naseef <ar...@amlinv.com> wrote:
> >
> > That makes sense then - having a separate repo and release cycle for the
> > native JNI library.
> >
> > Perhaps, as Jeff suggested, ActiveMQ-Artemis-native would be a good name?
> >
> > Art
> >
> >
> > On Thu, Jan 31, 2019 at 10:04 AM Clebert Suconic <
> clebert.suconic@gmail.com>
> > wrote:
> >
> > > 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
> > > <cl...@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 <ar...@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.suconic@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 <ar...@amlinv.com>
> wrote:
> > > >> >
> > > >> > > What is in the library?
> > > >> > >
> > > >> > > Art
> > > >> > >
> > > >> > >
> > > >> > > On Wed, Jan 30, 2019 at 11:08 AM Clebert Suconic <
> > > >> > > clebert.suconic@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 <
> jgenender@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
> > >
>
>
>
> --
> Clebert Suconic
>
Re: [DISCUSS] ActiveMQ Artemis Native as a separated project
Posted by Clebert Suconic <cl...@gmail.com>.
The Project has been already created here. It includes the original
logs from the activemq-artemis folder.
https://github.com/apache/activemq-artemis-native
I will send a separate HEADS up to make a release tomorrow.
On Mon, Feb 25, 2019 at 12:33 PM Clebert Suconic
<cl...@gmail.com> wrote:
>
> As a Heads-UP. We have been separating the history on this repository here:
>
> https://github.com/clebertsuconic/activemq-artemis-native
>
> Which is now ready to go.
>
> so I will go ahead and create the github repository tomorrow. and add
> these bits in there.
> I plan to make a first release soon, so I will be working on providing
> a download page.
>
>
>
> And BTW: I have done some progress on how the natives are compiled.
> There's a script that will create a docker image, and use it to
> generate the binaries. So the only building dependency you will need
> is docker. (kind of cool actually).
>
> you will still be able to build it on your own box if you want... but
> this will make it easier to generate the releases.
>
>
>
> I will send another HEADS-UP for a release as soon as I'm ready.
>
> On Fri, Feb 1, 2019 at 7:38 AM Christopher Shannon
> <ch...@gmail.com> wrote:
> >
> > It makes sense to me to have a separate release cycle for the JNI parts. I
> > think lazy consensus is fine here and as long no one objects you can just
> > go ahead and create it without a formal vote.
> >
> > On Thu, Jan 31, 2019 at 3:51 PM Clebert Suconic <cl...@gmail.com>
> > wrote:
> >
> > > yep, so far the best name is ActiveMQ-Artemis-native
> > >
> > >
> > > I don't think this is a big deal and I don't intend to create a vote
> > > for this.. as this is regular business. We are creating a separate
> > > repository for the native part, not a project!
> > >
> > > Let me know If you anyone think I'm wrong and this needs a vote please.
> > >
> > > On Thu, Jan 31, 2019 at 1:59 PM Arthur Naseef <ar...@amlinv.com> wrote:
> > > >
> > > > That makes sense then - having a separate repo and release cycle for the
> > > > native JNI library.
> > > >
> > > > Perhaps, as Jeff suggested, ActiveMQ-Artemis-native would be a good name?
> > > >
> > > > Art
> > > >
> > > >
> > > > On Thu, Jan 31, 2019 at 10:04 AM Clebert Suconic <
> > > clebert.suconic@gmail.com>
> > > > wrote:
> > > >
> > > > > 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
> > > > > <cl...@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 <ar...@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.suconic@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 <ar...@amlinv.com>
> > > wrote:
> > > > > >> >
> > > > > >> > > What is in the library?
> > > > > >> > >
> > > > > >> > > Art
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > On Wed, Jan 30, 2019 at 11:08 AM Clebert Suconic <
> > > > > >> > > clebert.suconic@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 <
> > > jgenender@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
> > > > >
> > >
> > >
> > >
> > > --
> > > Clebert Suconic
> > >
>
>
>
> --
> Clebert Suconic
--
Clebert Suconic
Re: [DISCUSS] ActiveMQ Artemis Native as a separated project
Posted by Clebert Suconic <cl...@gmail.com>.
As a Heads-UP. We have been separating the history on this repository here:
https://github.com/clebertsuconic/activemq-artemis-native
Which is now ready to go.
so I will go ahead and create the github repository tomorrow. and add
these bits in there.
I plan to make a first release soon, so I will be working on providing
a download page.
And BTW: I have done some progress on how the natives are compiled.
There's a script that will create a docker image, and use it to
generate the binaries. So the only building dependency you will need
is docker. (kind of cool actually).
you will still be able to build it on your own box if you want... but
this will make it easier to generate the releases.
I will send another HEADS-UP for a release as soon as I'm ready.
On Fri, Feb 1, 2019 at 7:38 AM Christopher Shannon
<ch...@gmail.com> wrote:
>
> It makes sense to me to have a separate release cycle for the JNI parts. I
> think lazy consensus is fine here and as long no one objects you can just
> go ahead and create it without a formal vote.
>
> On Thu, Jan 31, 2019 at 3:51 PM Clebert Suconic <cl...@gmail.com>
> wrote:
>
> > yep, so far the best name is ActiveMQ-Artemis-native
> >
> >
> > I don't think this is a big deal and I don't intend to create a vote
> > for this.. as this is regular business. We are creating a separate
> > repository for the native part, not a project!
> >
> > Let me know If you anyone think I'm wrong and this needs a vote please.
> >
> > On Thu, Jan 31, 2019 at 1:59 PM Arthur Naseef <ar...@amlinv.com> wrote:
> > >
> > > That makes sense then - having a separate repo and release cycle for the
> > > native JNI library.
> > >
> > > Perhaps, as Jeff suggested, ActiveMQ-Artemis-native would be a good name?
> > >
> > > Art
> > >
> > >
> > > On Thu, Jan 31, 2019 at 10:04 AM Clebert Suconic <
> > clebert.suconic@gmail.com>
> > > wrote:
> > >
> > > > 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
> > > > <cl...@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 <ar...@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.suconic@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 <ar...@amlinv.com>
> > wrote:
> > > > >> >
> > > > >> > > What is in the library?
> > > > >> > >
> > > > >> > > Art
> > > > >> > >
> > > > >> > >
> > > > >> > > On Wed, Jan 30, 2019 at 11:08 AM Clebert Suconic <
> > > > >> > > clebert.suconic@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 <
> > jgenender@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
> > > >
> >
> >
> >
> > --
> > Clebert Suconic
> >
--
Clebert Suconic