You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Martyn Taylor <mt...@redhat.com> on 2015/12/18 18:36:15 UTC
[VOTE] Apache Artemis 1.2.0
Hello all.
I'd like to propose an Apache Artemis 1.2.0 release.
Since 1.1.0 we've had some significant improvements to performance,
particularly around the persistence layer. In addition new features
have been added such as LDAP and OSGi support. There has also been more
improvements to the OpenWire protocol.
The release notes can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12333274
The binary distributions can be found here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
The source archives can be found here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
The Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1076/
The source tag:
https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.2.0
The project website for that version has been staged to:
http://people.apache.org/~martyntaylor/
The vote will remain open for 72 hours.
[ ] +1 approve the release as Apache Artemis 1.2.0
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)
Here's my (non-binding) +1
Regards
Martyn
Re: [VOTE] Apache Artemis 1.2.0
Posted by "John D. Ament" <jo...@apache.org>.
On Mon, Dec 21, 2015 at 12:55 PM Clebert Suconic <cl...@gmail.com>
wrote:
> >
> > Actually, this is more serious than that. If I’m reading correctly,
> libaio is LGPL. Thus, we cannot use it from an Apache release unless its:
> >
> We are not redistributing libaio.. libaio is a Kernel functionality
> from Linux. We have an implementation that is just using a kernel
> functionality available on any Linux Kernel. you need to install the
> libaio header but the functiionality is part of the linux kernel.
>
> Saying so would be the same as saying you can't use any OS that's
> LGPL.. which is not the case.
>
>
>
> > 1) completely optional - Artemis would have to “functionally work”
> without it
> >
>
> It does, however we get a lot of performance boos if you use it.
>
>
> > 2) Not be part of the default build - in our case, we’d need a maven
> profile to build it and that profile would need to not be activeByDefault.
> >
> > Thus, I think this release cannot be released as is.
>
>
> I disagree.. the release should include it... our implementation is
> apache licensed.
>
I'm assuming that it's accessed like a DLL?
Is libaio required to compile the library?
Re: [VOTE] Apache Artemis 1.2.0
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Mon, Dec 21, 2015 at 1:22 PM, Hiram Chirino <hi...@hiramchirino.com> wrote:
> To me this seem the same as linking to glibc which is an LGLP lib and
> a lib which just about every app on linux links to. Surely even apr
> links to it right?
>
> This can also be seen a linking against hibernate, but not distributing it.
>
And it seems other apache projects are doing that. See:
https://github.com/apache/tapestry5/blob/5.0/tapestry-hibernate/pom.xml
--
Hiram Chirino
Engineering | Red Hat, Inc.
hchirino@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
Re: [VOTE] Apache Artemis 1.2.0
Posted by Clebert Suconic <cl...@gmail.com>.
On Mon, Dec 21, 2015 at 1:22 PM, Hiram Chirino <hi...@hiramchirino.com> wrote:
> To me this seem the same as linking to glibc which is an LGLP lib and
> a lib which just about every app on linux links to. Surely even apr
> links to it right?
That's correct... just like anything else in the Linux world.
as a matter of fact this code requires glibc as well.
Re: [VOTE] Apache Artemis 1.2.0
Posted by Hiram Chirino <hi...@hiramchirino.com>.
To me this seem the same as linking to glibc which is an LGLP lib and
a lib which just about every app on linux links to. Surely even apr
links to it right?
This can also be seen a linking against hibernate, but not distributing it.
On Mon, Dec 21, 2015 at 1:10 PM, Daniel Kulp <dk...@apache.org> wrote:
>
>> On Dec 21, 2015, at 1:08 PM, Clebert Suconic <cl...@gmail.com> wrote:
>>
>> In particular, in org_apache_activemq_artemis_jlibaio_LibaioContext.c,
>> I see right at the top:
>>
>> #ifndef _GNU_SOURCE
>> // libaio, O_DIRECT and other things won't be available without this define
>> #define _GNU_SOURCE
>> #endif
>>
>>
>> this has nothing to do with LGPL licenses.. or even libaio on this
>> instance.. That's how you enable O_DIRECT, with O_DIRECT being a Linux
>> extension non conformant with POSIX. the header is there for any
>> source code using it.
>>
>>> …linked to libraries that are LGPL and only LGPL, which is not allowed per ASF policy.
>>>
>>
>> Dynamic linked.. it doesn't not include libaio.
>
> But is still REQUIRED for building the library… Thus, the library still has a REQUIRED dependency on a LGPL’d library to work. Thus, it must be optional and the user must take explicit actions to enable it during build and runtime.
>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
--
Hiram Chirino
Engineering | Red Hat, Inc.
hchirino@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
Re: [VOTE] Apache Artemis 1.2.0
Posted by Clebert Suconic <cl...@gmail.com>.
> But is still REQUIRED for building the library… Thus, the library still has a REQUIRED dependency on a LGPL’d library to work. Thus, it must be optional and the user must take explicit actions to enable it during build and runtime.
>>has a REQUIRED dependency on a LGPL’d library to work<<
if the library is not available, we won't use it... the use is optional.
The compilation is required to validate method calls. It would be
actually possible to compile the library without the actual libaio
installed, but I don't want to go that route as it would complicate
the build and code. But the use is still dynamic linked.
Re: [VOTE] Apache Artemis 1.2.0
Posted by Daniel Kulp <dk...@apache.org>.
> On Dec 21, 2015, at 1:08 PM, Clebert Suconic <cl...@gmail.com> wrote:
>
> In particular, in org_apache_activemq_artemis_jlibaio_LibaioContext.c,
> I see right at the top:
>
> #ifndef _GNU_SOURCE
> // libaio, O_DIRECT and other things won't be available without this define
> #define _GNU_SOURCE
> #endif
>
>
> this has nothing to do with LGPL licenses.. or even libaio on this
> instance.. That's how you enable O_DIRECT, with O_DIRECT being a Linux
> extension non conformant with POSIX. the header is there for any
> source code using it.
>
>> …linked to libraries that are LGPL and only LGPL, which is not allowed per ASF policy.
>>
>
> Dynamic linked.. it doesn't not include libaio.
But is still REQUIRED for building the library… Thus, the library still has a REQUIRED dependency on a LGPL’d library to work. Thus, it must be optional and the user must take explicit actions to enable it during build and runtime.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache Artemis 1.2.0
Posted by Clebert Suconic <cl...@gmail.com>.
In particular, in org_apache_activemq_artemis_jlibaio_LibaioContext.c,
I see right at the top:
#ifndef _GNU_SOURCE
// libaio, O_DIRECT and other things won't be available without this define
#define _GNU_SOURCE
#endif
this has nothing to do with LGPL licenses.. or even libaio on this
instance.. That's how you enable O_DIRECT, with O_DIRECT being a Linux
extension non conformant with POSIX. the header is there for any
source code using it.
> …linked to libraries that are LGPL and only LGPL, which is not allowed per ASF policy.
>
Dynamic linked.. it doesn't not include libaio.
Re: [VOTE] Apache Artemis 1.2.0
Posted by Daniel Kulp <dk...@apache.org>.
> On Dec 21, 2015, at 12:55 PM, Clebert Suconic <cl...@gmail.com> wrote:
>
>>
>> Actually, this is more serious than that. If I’m reading correctly, libaio is LGPL. Thus, we cannot use it from an Apache release unless its:
>>
> We are not redistributing libaio.. libaio is a Kernel functionality
> from Linux. We have an implementation that is just using a kernel
> functionality available on any Linux Kernel. you need to install the
> libaio header but the functiionality is part of the linux kernel.
>
> Saying so would be the same as saying you can't use any OS that's
> LGPL.. which is not the case.
But the parts of the “OS” that is used generally has some sort of “classpath exception” or similar or there is another implementation that is completely usable that is not LGPL (example: the stdc++ runtimes). libaio does not. It is specifically LGPL.
In particular, in org_apache_activemq_artemis_jlibaio_LibaioContext.c, I see right at the top:
#ifndef _GNU_SOURCE
// libaio, O_DIRECT and other things won't be available without this define
#define _GNU_SOURCE
#endif
That’s in direct conflict with the license header.
>> 2) Not be part of the default build - in our case, we’d need a maven profile to build it and that profile would need to not be activeByDefault.
>>
>> Thus, I think this release cannot be released as is.
>
> I disagree.. the release should include it... our implementation is
> apache licensed.
…linked to libraries that are LGPL and only LGPL, which is not allowed per ASF policy.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache Artemis 1.2.0
Posted by Clebert Suconic <cl...@gmail.com>.
>
> Actually, this is more serious than that. If I’m reading correctly, libaio is LGPL. Thus, we cannot use it from an Apache release unless its:
>
We are not redistributing libaio.. libaio is a Kernel functionality
from Linux. We have an implementation that is just using a kernel
functionality available on any Linux Kernel. you need to install the
libaio header but the functiionality is part of the linux kernel.
Saying so would be the same as saying you can't use any OS that's
LGPL.. which is not the case.
> 1) completely optional - Artemis would have to “functionally work” without it
>
It does, however we get a lot of performance boos if you use it.
> 2) Not be part of the default build - in our case, we’d need a maven profile to build it and that profile would need to not be activeByDefault.
>
> Thus, I think this release cannot be released as is.
I disagree.. the release should include it... our implementation is
apache licensed.
Re: [VOTE] Apache Artemis 1.2.0
Posted by Daniel Kulp <dk...@apache.org>.
> On Dec 21, 2015, at 12:27 PM, John D. Ament <jo...@apache.org> wrote:
>
> On Mon, Dec 21, 2015 at 12:16 PM Clebert Suconic <cl...@gmail.com>
> wrote:
>
>> This has been like this since 1.0.0
>>
>>
> Then I missed them in prior votes. Mea culpa.
We all missed them on the prior releases.
>>
>> I don't want to require users to install cmake and make just to
>> compile this small library. it should be an optional step for those
>> who want to do it.
>>
>
> Nothing's stopping you from including them in the binary release. They
> should be excluded in the source release.
Actually, this is more serious than that. If I’m reading correctly, libaio is LGPL. Thus, we cannot use it from an Apache release unless its:
1) completely optional - Artemis would have to “functionally work” without it
2) Not be part of the default build - in our case, we’d need a maven profile to build it and that profile would need to not be activeByDefault.
Thus, I think this release cannot be released as is.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache Artemis 1.2.0
Posted by Clebert Suconic <cl...@gmail.com>.
> Per Roy Fielding:
>
> "Apache releases open source and ONLY open source. Our releases are absolutely
> forbidden to contain anything other than the open source code that is in our
> vcs-of-record, meaning code that is in the form most likely to be edited by
> recipients for the sake of modifying the product, and in some specific cases
> the generated (and open) source code of build scripts."
>
Ok, fair enough.. -1 (non binding) from me then...
I will remove it from the source distribution.
Re: [VOTE] Apache Artemis 1.2.0
Posted by "John D. Ament" <jo...@apache.org>.
On Dec 21, 2015 1:42 PM, "Daniel Kulp" <dk...@apache.org> wrote:
>
>
> > On Dec 21, 2015, at 12:41 PM, John D. Ament <jo...@apache.org>
wrote:
> >
> > On Mon, Dec 21, 2015 at 12:34 PM Clebert Suconic <
clebert.suconic@gmail.com>
> > wrote:
> >
> >>> Nothing's stopping you from including them in the binary release.
They
> >>> should be excluded in the source release.
> >>
> >>
> >> It's been easier to keep these .so there. I'm about to give up
> >> maintaining 32 bits. but right now you would need to log on 32 bits..
> >> compile it.. log on 64 bits.. compile it..to make a full binary
> >> distribution from the source.
> >>
> >> removing the .so will only complicate things.. I don't think we should
> >> be so purist on this matter.
> >>
> >
> > I think you're thinking about removing the .so's from the git repo. I'm
> > not requesting that. They simply can't be in the source release
tar.gz/zip
> > archives.
>
>
> Back to this part, the DO have to be removed from the source tar.gz.
>
> Per Roy Fielding:
>
> "Apache releases open source and ONLY open source. Our releases are
absolutely
> forbidden to contain anything other than the open source code that is in
our
> vcs-of-record, meaning code that is in the form most likely to be edited
by
> recipients for the sake of modifying the product, and in some specific
cases
> the generated (and open) source code of build scripts."
>
>
http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3CC3656B87-A6DC-4D3D-B1EB-29911B7A8070%40gbiv.com%3E
>
> So yes, this part MUST be done.
I'd recommend tabling the lgpl license issue and bringing it up on
legal-discuss.
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
Re: [VOTE] Apache Artemis 1.2.0
Posted by Daniel Kulp <dk...@apache.org>.
> On Dec 21, 2015, at 12:41 PM, John D. Ament <jo...@apache.org> wrote:
>
> On Mon, Dec 21, 2015 at 12:34 PM Clebert Suconic <cl...@gmail.com>
> wrote:
>
>>> Nothing's stopping you from including them in the binary release. They
>>> should be excluded in the source release.
>>
>>
>> It's been easier to keep these .so there. I'm about to give up
>> maintaining 32 bits. but right now you would need to log on 32 bits..
>> compile it.. log on 64 bits.. compile it..to make a full binary
>> distribution from the source.
>>
>> removing the .so will only complicate things.. I don't think we should
>> be so purist on this matter.
>>
>
> I think you're thinking about removing the .so's from the git repo. I'm
> not requesting that. They simply can't be in the source release tar.gz/zip
> archives.
Back to this part, the DO have to be removed from the source tar.gz.
Per Roy Fielding:
"Apache releases open source and ONLY open source. Our releases are absolutely
forbidden to contain anything other than the open source code that is in our
vcs-of-record, meaning code that is in the form most likely to be edited by
recipients for the sake of modifying the product, and in some specific cases
the generated (and open) source code of build scripts."
http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3CC3656B87-A6DC-4D3D-B1EB-29911B7A8070%40gbiv.com%3E
So yes, this part MUST be done.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache Artemis 1.2.0
Posted by "John D. Ament" <jo...@apache.org>.
On Mon, Dec 21, 2015 at 12:34 PM Clebert Suconic <cl...@gmail.com>
wrote:
> > Nothing's stopping you from including them in the binary release. They
> > should be excluded in the source release.
>
>
> It's been easier to keep these .so there. I'm about to give up
> maintaining 32 bits. but right now you would need to log on 32 bits..
> compile it.. log on 64 bits.. compile it..to make a full binary
> distribution from the source.
>
> removing the .so will only complicate things.. I don't think we should
> be so purist on this matter.
>
I think you're thinking about removing the .so's from the git repo. I'm
not requesting that. They simply can't be in the source release tar.gz/zip
archives.
John
>
> Although if more people think this is an issue.. I'm always reasonable
> to change my opinion.. I have been doing this way just to make it
> easier on people building it.
>
Re: [VOTE] Apache Artemis 1.2.0
Posted by Clebert Suconic <cl...@gmail.com>.
> Nothing's stopping you from including them in the binary release. They
> should be excluded in the source release.
It's been easier to keep these .so there. I'm about to give up
maintaining 32 bits. but right now you would need to log on 32 bits..
compile it.. log on 64 bits.. compile it..to make a full binary
distribution from the source.
removing the .so will only complicate things.. I don't think we should
be so purist on this matter.
Although if more people think this is an issue.. I'm always reasonable
to change my opinion.. I have been doing this way just to make it
easier on people building it.
Re: [VOTE] Apache Artemis 1.2.0
Posted by "John D. Ament" <jo...@apache.org>.
On Mon, Dec 21, 2015 at 12:16 PM Clebert Suconic <cl...@gmail.com>
wrote:
> This has been like this since 1.0.0
>
>
Then I missed them in prior votes. Mea culpa.
>
> The binaries are there for being easy of use for users who only want
> to build the jars. If they want to build the native part they can just
> refer to http://activemq.apache.org/artemis/docs/1.1.0/libaio.html
>
>
> and use cmake . and make.
>
> and this is just on Linux BTW. It's not supposed to be compiled on
> anything else other than windows.
>
>
> I don't want to require users to install cmake and make just to
> compile this small library. it should be an optional step for those
> who want to do it.
>
Nothing's stopping you from including them in the binary release. They
should be excluded in the source release.
>
> On Mon, Dec 21, 2015 at 11:42 AM, John D. Ament <jo...@apache.org>
> wrote:
> > Sorry but -1 (non-binding)
> >
> > There are binary files in the source release, under artemis-native/bin/
> >
> > Ideally, the source release would include the C/C++ code required to
> build
> > these so's, but I'm not sure that they're anywhere in the artemis
> codebase.
> >
> > In addition, compiling on a mac, latest patches, I can't build the source
> > release on 1.8.0_u51 with the following error:
> >
> > Error: Could not find or load main class
> > 2.artemis-commons....tests.config.logging.properties
> >
> >
> > Results :
> >
> >
> > Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> >
> >
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test)
> > on project artemis-commons: Execution default-test of goal
> > org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test failed: The
> > forked VM terminated without properly saying goodbye. VM crash or
> > System.exit called?
> >
> > [ERROR] Command was /bin/sh -c cd
> > "/Users/johnament/Downloads/apache-artemis-1.2.0 2/artemis-commons" &&
> >
> /Library/Java/JavaVirtualMachines/jdk1.8.0_51.jdk/Contents/Home/jre/bin/java
> > -Djava.util.logging.manager=org.jboss.logmanager.LogManager
> >
> -Dlogging.configuration=file:/Users/johnament/Downloads/apache-artemis-1.2.0
> > 2/artemis-commons/../tests/config/logging.properties
> > -Djava.library.path=/Users/johnament/Downloads/apache-artemis-1.2.0
> > 2/artemis-commons/../artemis-native/bin/ -Djgroups.bind_addr=localhost
> >
> -Dorg.apache.activemq.artemis.api.core.UDPBroadcastEndpointFactory.localBindAddress=localhost
> > -Djava.net.preferIPv4Stack=true -jar
> > '/Users/johnament/Downloads/apache-artemis-1.2.0
> > 2/artemis-commons/target/surefire/surefirebooter197336116502841627.jar'
> > '/Users/johnament/Downloads/apache-artemis-1.2.0
> > 2/artemis-commons/target/surefire/surefire8924091653426997785tmp'
> > '/Users/johnament/Downloads/apache-artemis-1.2.0
> > 2/artemis-commons/target/surefire/surefire_03004869270640953611tmp'
> >
> > [ERROR] -> [Help 1]
> >
> > On Fri, Dec 18, 2015 at 12:36 PM Martyn Taylor <mt...@redhat.com>
> wrote:
> >
> >> Hello all.
> >>
> >> I'd like to propose an Apache Artemis 1.2.0 release.
> >>
> >> Since 1.1.0 we've had some significant improvements to performance,
> >> particularly around the persistence layer. In addition new features
> >> have been added such as LDAP and OSGi support. There has also been more
> >> improvements to the OpenWire protocol.
> >>
> >> The release notes can be found here:
> >>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12333274
> >>
> >>
> >> The binary distributions can be found here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
> >>
> >>
> >> The source archives can be found here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
> >>
> >>
> >> The Maven repository is here:
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/
> >>
> >> The source tag:
> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.2.0
> >>
> >>
> >> The project website for that version has been staged to:
> >> http://people.apache.org/~martyntaylor/
> >>
> >> The vote will remain open for 72 hours.
> >>
> >> [ ] +1 approve the release as Apache Artemis 1.2.0
> >> [ ] +0 no opinion
> >> [ ] -1 disapprove (and reason why)
> >>
> >> Here's my (non-binding) +1
> >>
> >> Regards
> >>
> >> Martyn
> >>
>
>
>
> --
> Clebert Suconic
>
Re: [VOTE] Apache Artemis 1.2.0
Posted by Clebert Suconic <cl...@gmail.com>.
This has been like this since 1.0.0
The binaries are there for being easy of use for users who only want
to build the jars. If they want to build the native part they can just
refer to http://activemq.apache.org/artemis/docs/1.1.0/libaio.html
and use cmake . and make.
and this is just on Linux BTW. It's not supposed to be compiled on
anything else other than windows.
I don't want to require users to install cmake and make just to
compile this small library. it should be an optional step for those
who want to do it.
On Mon, Dec 21, 2015 at 11:42 AM, John D. Ament <jo...@apache.org> wrote:
> Sorry but -1 (non-binding)
>
> There are binary files in the source release, under artemis-native/bin/
>
> Ideally, the source release would include the C/C++ code required to build
> these so's, but I'm not sure that they're anywhere in the artemis codebase.
>
> In addition, compiling on a mac, latest patches, I can't build the source
> release on 1.8.0_u51 with the following error:
>
> Error: Could not find or load main class
> 2.artemis-commons....tests.config.logging.properties
>
>
> Results :
>
>
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
>
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test)
> on project artemis-commons: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test failed: The
> forked VM terminated without properly saying goodbye. VM crash or
> System.exit called?
>
> [ERROR] Command was /bin/sh -c cd
> "/Users/johnament/Downloads/apache-artemis-1.2.0 2/artemis-commons" &&
> /Library/Java/JavaVirtualMachines/jdk1.8.0_51.jdk/Contents/Home/jre/bin/java
> -Djava.util.logging.manager=org.jboss.logmanager.LogManager
> -Dlogging.configuration=file:/Users/johnament/Downloads/apache-artemis-1.2.0
> 2/artemis-commons/../tests/config/logging.properties
> -Djava.library.path=/Users/johnament/Downloads/apache-artemis-1.2.0
> 2/artemis-commons/../artemis-native/bin/ -Djgroups.bind_addr=localhost
> -Dorg.apache.activemq.artemis.api.core.UDPBroadcastEndpointFactory.localBindAddress=localhost
> -Djava.net.preferIPv4Stack=true -jar
> '/Users/johnament/Downloads/apache-artemis-1.2.0
> 2/artemis-commons/target/surefire/surefirebooter197336116502841627.jar'
> '/Users/johnament/Downloads/apache-artemis-1.2.0
> 2/artemis-commons/target/surefire/surefire8924091653426997785tmp'
> '/Users/johnament/Downloads/apache-artemis-1.2.0
> 2/artemis-commons/target/surefire/surefire_03004869270640953611tmp'
>
> [ERROR] -> [Help 1]
>
> On Fri, Dec 18, 2015 at 12:36 PM Martyn Taylor <mt...@redhat.com> wrote:
>
>> Hello all.
>>
>> I'd like to propose an Apache Artemis 1.2.0 release.
>>
>> Since 1.1.0 we've had some significant improvements to performance,
>> particularly around the persistence layer. In addition new features
>> have been added such as LDAP and OSGi support. There has also been more
>> improvements to the OpenWire protocol.
>>
>> The release notes can be found here:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12333274
>>
>>
>> The binary distributions can be found here:
>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
>>
>>
>> The source archives can be found here:
>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
>>
>>
>> The Maven repository is here:
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/
>>
>> The source tag:
>>
>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.2.0
>>
>>
>> The project website for that version has been staged to:
>> http://people.apache.org/~martyntaylor/
>>
>> The vote will remain open for 72 hours.
>>
>> [ ] +1 approve the release as Apache Artemis 1.2.0
>> [ ] +0 no opinion
>> [ ] -1 disapprove (and reason why)
>>
>> Here's my (non-binding) +1
>>
>> Regards
>>
>> Martyn
>>
--
Clebert Suconic
Re: [VOTE] Apache Artemis 1.2.0
Posted by "John D. Ament" <jo...@apache.org>.
On Mon, Dec 21, 2015 at 2:44 PM Clebert Suconic <cl...@gmail.com>
wrote:
> On Mon, Dec 21, 2015 at 2:37 PM, John D. Ament <jo...@apache.org>
> wrote:
> > So... create a ticket to track this? I can compile other stuff with
> spaces
> > generally fine. Not sure what the issue is here w/ a space.
>
>
> yep.. I don't think it's a release blocker. although if someone is
> able to pick it up we can have it before next respin.
>
The space issue comes from this configuration in the root pom
<activemq-surefire-argline>-Djava.util.logging.manager=org.jboss.logmanager.LogManager
-Dlogging.configuration=file:${activemq.basedir}/tests/config/logging.properties
-Djava.library.path=${activemq.basedir}/artemis-native/bin/
-Djgroups.bind_addr=localhost
-Dorg.apache.activemq.artemis.api.core.UDPBroadcastEndpointFactory.localBindAddress=localhost
-Djava.net.preferIPv4Stack=true
</activemq-surefire-argline>
I'll see if there's a way to fix it.
Re: [VOTE] Apache Artemis 1.2.0
Posted by Clebert Suconic <cl...@gmail.com>.
On Mon, Dec 21, 2015 at 2:37 PM, John D. Ament <jo...@apache.org> wrote:
> So... create a ticket to track this? I can compile other stuff with spaces
> generally fine. Not sure what the issue is here w/ a space.
yep.. I don't think it's a release blocker. although if someone is
able to pick it up we can have it before next respin.
Re: [VOTE] Apache Artemis 1.2.0
Posted by "John D. Ament" <jo...@apache.org>.
So... create a ticket to track this? I can compile other stuff with spaces
generally fine. Not sure what the issue is here w/ a space.
On Mon, Dec 21, 2015 at 2:30 PM Clebert Suconic <cl...@gmail.com>
wrote:
> > [ERROR] Command was /bin/sh -c cd
> > "/Users/johnament/Downloads/apache-artemis-1.2.0 2/artemis-commons" &&
> >
> /Library/Java/JavaVirtualMachines/jdk1.8.0_51.jdk/Contents/Home/jre/bin/java
>
>
>
> The compilation issue is because you used a space ' ' on your directory
>
> had you used apache-artemis-1.2.0_2 (instead of space) it would have
> worked fine. I replicated it here with a " " as well on a mac (dunno
> about other envs.. probably the same).
>
Re: [VOTE] Apache Artemis 1.2.0
Posted by Clebert Suconic <cl...@gmail.com>.
> [ERROR] Command was /bin/sh -c cd
> "/Users/johnament/Downloads/apache-artemis-1.2.0 2/artemis-commons" &&
> /Library/Java/JavaVirtualMachines/jdk1.8.0_51.jdk/Contents/Home/jre/bin/java
The compilation issue is because you used a space ' ' on your directory
had you used apache-artemis-1.2.0_2 (instead of space) it would have
worked fine. I replicated it here with a " " as well on a mac (dunno
about other envs.. probably the same).
[CANCEL][VOTE] Apache Artemis 1.2.0
Posted by Martyn Taylor <mt...@redhat.com>.
Cancelling vote, due to binaries in the source distro.
We are getting very close to the holiday period now, so let's pick the
1.2.0 release up after the new year.
Happy holidays all!
Regards
Martyn
On 21/12/15 16:42, John D. Ament wrote:
> Sorry but -1 (non-binding)
>
> There are binary files in the source release, under artemis-native/bin/
>
> Ideally, the source release would include the C/C++ code required to build
> these so's, but I'm not sure that they're anywhere in the artemis codebase.
>
> In addition, compiling on a mac, latest patches, I can't build the source
> release on 1.8.0_u51 with the following error:
>
> Error: Could not find or load main class
> 2.artemis-commons....tests.config.logging.properties
>
>
> Results :
>
>
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
>
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test)
> on project artemis-commons: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test failed: The
> forked VM terminated without properly saying goodbye. VM crash or
> System.exit called?
>
> [ERROR] Command was /bin/sh -c cd
> "/Users/johnament/Downloads/apache-artemis-1.2.0 2/artemis-commons" &&
> /Library/Java/JavaVirtualMachines/jdk1.8.0_51.jdk/Contents/Home/jre/bin/java
> -Djava.util.logging.manager=org.jboss.logmanager.LogManager
> -Dlogging.configuration=file:/Users/johnament/Downloads/apache-artemis-1.2.0
> 2/artemis-commons/../tests/config/logging.properties
> -Djava.library.path=/Users/johnament/Downloads/apache-artemis-1.2.0
> 2/artemis-commons/../artemis-native/bin/ -Djgroups.bind_addr=localhost
> -Dorg.apache.activemq.artemis.api.core.UDPBroadcastEndpointFactory.localBindAddress=localhost
> -Djava.net.preferIPv4Stack=true -jar
> '/Users/johnament/Downloads/apache-artemis-1.2.0
> 2/artemis-commons/target/surefire/surefirebooter197336116502841627.jar'
> '/Users/johnament/Downloads/apache-artemis-1.2.0
> 2/artemis-commons/target/surefire/surefire8924091653426997785tmp'
> '/Users/johnament/Downloads/apache-artemis-1.2.0
> 2/artemis-commons/target/surefire/surefire_03004869270640953611tmp'
>
> [ERROR] -> [Help 1]
>
> On Fri, Dec 18, 2015 at 12:36 PM Martyn Taylor <mt...@redhat.com> wrote:
>
>> Hello all.
>>
>> I'd like to propose an Apache Artemis 1.2.0 release.
>>
>> Since 1.1.0 we've had some significant improvements to performance,
>> particularly around the persistence layer. In addition new features
>> have been added such as LDAP and OSGi support. There has also been more
>> improvements to the OpenWire protocol.
>>
>> The release notes can be found here:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12333274
>>
>>
>> The binary distributions can be found here:
>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
>>
>>
>> The source archives can be found here:
>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
>>
>>
>> The Maven repository is here:
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/
>>
>> The source tag:
>>
>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.2.0
>>
>>
>> The project website for that version has been staged to:
>> http://people.apache.org/~martyntaylor/
>>
>> The vote will remain open for 72 hours.
>>
>> [ ] +1 approve the release as Apache Artemis 1.2.0
>> [ ] +0 no opinion
>> [ ] -1 disapprove (and reason why)
>>
>> Here's my (non-binding) +1
>>
>> Regards
>>
>> Martyn
>>
Re: [VOTE] Apache Artemis 1.2.0
Posted by "John D. Ament" <jo...@apache.org>.
Sorry but -1 (non-binding)
There are binary files in the source release, under artemis-native/bin/
Ideally, the source release would include the C/C++ code required to build
these so's, but I'm not sure that they're anywhere in the artemis codebase.
In addition, compiling on a mac, latest patches, I can't build the source
release on 1.8.0_u51 with the following error:
Error: Could not find or load main class
2.artemis-commons....tests.config.logging.properties
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test)
on project artemis-commons: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test failed: The
forked VM terminated without properly saying goodbye. VM crash or
System.exit called?
[ERROR] Command was /bin/sh -c cd
"/Users/johnament/Downloads/apache-artemis-1.2.0 2/artemis-commons" &&
/Library/Java/JavaVirtualMachines/jdk1.8.0_51.jdk/Contents/Home/jre/bin/java
-Djava.util.logging.manager=org.jboss.logmanager.LogManager
-Dlogging.configuration=file:/Users/johnament/Downloads/apache-artemis-1.2.0
2/artemis-commons/../tests/config/logging.properties
-Djava.library.path=/Users/johnament/Downloads/apache-artemis-1.2.0
2/artemis-commons/../artemis-native/bin/ -Djgroups.bind_addr=localhost
-Dorg.apache.activemq.artemis.api.core.UDPBroadcastEndpointFactory.localBindAddress=localhost
-Djava.net.preferIPv4Stack=true -jar
'/Users/johnament/Downloads/apache-artemis-1.2.0
2/artemis-commons/target/surefire/surefirebooter197336116502841627.jar'
'/Users/johnament/Downloads/apache-artemis-1.2.0
2/artemis-commons/target/surefire/surefire8924091653426997785tmp'
'/Users/johnament/Downloads/apache-artemis-1.2.0
2/artemis-commons/target/surefire/surefire_03004869270640953611tmp'
[ERROR] -> [Help 1]
On Fri, Dec 18, 2015 at 12:36 PM Martyn Taylor <mt...@redhat.com> wrote:
> Hello all.
>
> I'd like to propose an Apache Artemis 1.2.0 release.
>
> Since 1.1.0 we've had some significant improvements to performance,
> particularly around the persistence layer. In addition new features
> have been added such as LDAP and OSGi support. There has also been more
> improvements to the OpenWire protocol.
>
> The release notes can be found here:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12333274
>
>
> The binary distributions can be found here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
>
>
> The source archives can be found here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
>
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/
>
> The source tag:
>
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.2.0
>
>
> The project website for that version has been staged to:
> http://people.apache.org/~martyntaylor/
>
> The vote will remain open for 72 hours.
>
> [ ] +1 approve the release as Apache Artemis 1.2.0
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here's my (non-binding) +1
>
> Regards
>
> Martyn
>
Re: [VOTE] Apache Artemis 1.2.0
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Great, thanks for the update !
Regards
JB
On 01/04/2016 10:59 AM, Martyn Taylor wrote:
> All,
>
> Re: The legal issues with the use of LibAIO.
>
> The response from apache-legal is that the use of LibAIO in the context
> of Apache Artemis is OK and does not pose any legal concerns. I realise
> there is an on going side discussion regarding legal documentation and
> perhaps contradictions between legal stances on Artemis and other
> projects. But, given we've had the OK from several board members, I am
> keen to go ahead and cut the next RC.
>
> The legal discussion thread can be found here:
> https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201512.mbox/%3C567BDDC1.8060805@redhat.com%3E
>
>
> The next RC will have addressed the issues with binary inclusions in the
> src release and also the great usability feedback provided by Claus
> Ibsen. It should be with you very soon.
>
> Regards
> Martyn
>
> On 24/12/15 12:01, Martyn Taylor wrote:
>> I have sent an email to the legal-discuss describing the issue. Please
>> follow the thread at the legal-discuss list.
>>
>> On 24/12/15 11:15, Martyn Taylor wrote:
>>> I do not see what the issue is here. We are not *distributing* any
>>> LGPL licensed library. We simply use it, if it is available. As
>>> Hiram said, how does this differ from relying on bash or win32?
>>>
>>> To quote the legal docs: http://www.apache.org/legal/resolved.html
>>>
>>> ""
>>> CAN APACHE PROJECTS RELY ON COMPONENTS UNDER PROHIBITED LICENSES?¶
>>> <http://www.apache.org/legal/resolved.html#prohibited>
>>>
>>> Apache projects cannot distribute any such components. As with the
>>> previous question on platforms, the component can be relied on if the
>>> component's licence terms do not affect the Apache product's
>>> licensing. For example, using a GPL'ed tool during the build is OK.
>>> ""
>>>
>>> I'd prefer not to require a CLI option that requires a user to
>>> proactively enable the use of libaio. The ASYNCIO journal is what we
>>> recommend, and one of the main reasons we get such good performance
>>> on persisted messages, for this reason it should be default. I agree
>>> with Hiram in that changing the defaults would hinder user
>>> experience, as the default configuration is now considerably slower.
>>> Out of the box configuration should in my opinion be as close to
>>> optimum as we can. Having a user read the documentation, understand
>>> what ASYNCIO is, what benefits it has and then make a decision to
>>> enable it, is more effort.
>>>
>>> Rather than go around in circles arguing whether this is against
>>> licensing policy or not, I will fire an email to legal now and get a
>>> definitive answer.
>>>
>>> Regards
>>> Martyn
>>>
>>> On 23/12/15 21:12, Hiram Chirino wrote:
>>>> I think the binary distro uses the libaio.so if it's installed in your
>>>> system. Since it's optional, the broker should still start up fine
>>>> even if libaio is not installed, but it wont get used either.
>>>>
>>>> On Wed, Dec 23, 2015 at 4:05 PM, Daniel Kulp <dk...@apache.org> wrote:
>>>>> Question: If I grab Artemis 1.1.0 tarbal/zip and start up the
>>>>> broker “out of the box”, does it use libaio or not? If I
>>>>> specifically have to configure something (pass a flag, edit a
>>>>> config file, etc…) to enable use if the LGPL library, then fine.
>>>>> However, if it’s something that occurs completely automatically
>>>>> without the user even knowing that it’s occurring, then I have a
>>>>> major problem with it. It needs to be something that the user has
>>>>> to explicitly CHOOSE to use.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>>> On Dec 23, 2015, at 2:02 PM, Clebert Suconic
>>>>>> <cl...@gmail.com> wrote:
>>>>>>
>>>>>> also, there has also been questions about it during the donation
>>>>>> process.. licenses reviewed.. etc.. so I don't think we need to
>>>>>> open a
>>>>>> new discussions over this. the binary inclusion on the source was
>>>>>> something that was fixed now.
>>>>>>
>>>>>> The dependency on libaio on the C code is through through dynamic
>>>>>> linked library, and is the same as any C code depending on libc or
>>>>>> gcc.
>>>>>>
>>>>>> On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
>>>>>> <cl...@gmail.com> wrote:
>>>>>>> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament
>>>>>>> <jo...@apache.org> wrote:
>>>>>>>> Just wondering, does anyone plan to raise the LGPL question w/
>>>>>>>> legal
>>>>>>>> discuss? If we're waiting for the new year to do the next
>>>>>>>> release, would
>>>>>>>> be good to at least start the discussion.
>>>>>>>
>>>>>>> We had such discussion long ago with legal. I couldn't find that
>>>>>>> email
>>>>>>> on my inbox but we specifically asked questions about it. We were ok
>>>>>>> as I remember. Maybe someone else (Martyn?) will have it on their
>>>>>>> inboxes. For that reason I don't want to go over the same issue
>>>>>>> we had
>>>>>>> asked before.
>>>>>>>
>>>>>>> The use of libaio is optional anyways and the system works as
>>>>>>> expected. what also covers other questions we had here on this
>>>>>>> thread.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Clebert Suconic
>>>>> --
>>>>> Daniel Kulp
>>>>> dkulp@apache.org - http://dankulp.com/blog
>>>>> Talend Community Coder - http://coders.talend.com
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [VOTE] Apache Artemis 1.2.0
Posted by "John D. Ament" <jo...@apache.org>.
Awesome news!
On Jan 4, 2016 05:00, "Martyn Taylor" <mt...@redhat.com> wrote:
> All,
>
> Re: The legal issues with the use of LibAIO.
>
> The response from apache-legal is that the use of LibAIO in the context of
> Apache Artemis is OK and does not pose any legal concerns. I realise there
> is an on going side discussion regarding legal documentation and perhaps
> contradictions between legal stances on Artemis and other projects. But,
> given we've had the OK from several board members, I am keen to go ahead
> and cut the next RC.
>
> The legal discussion thread can be found here:
> https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201512.mbox/%3C567BDDC1.8060805@redhat.com%3E
>
> The next RC will have addressed the issues with binary inclusions in the
> src release and also the great usability feedback provided by Claus Ibsen.
> It should be with you very soon.
>
> Regards
> Martyn
>
> On 24/12/15 12:01, Martyn Taylor wrote:
>
>> I have sent an email to the legal-discuss describing the issue. Please
>> follow the thread at the legal-discuss list.
>>
>> On 24/12/15 11:15, Martyn Taylor wrote:
>>
>>> I do not see what the issue is here. We are not *distributing* any LGPL
>>> licensed library. We simply use it, if it is available. As Hiram said, how
>>> does this differ from relying on bash or win32?
>>>
>>> To quote the legal docs: http://www.apache.org/legal/resolved.html
>>>
>>> ""
>>> CAN APACHE PROJECTS RELY ON COMPONENTS UNDER PROHIBITED LICENSES?¶ <
>>> http://www.apache.org/legal/resolved.html#prohibited>
>>>
>>> Apache projects cannot distribute any such components. As with the
>>> previous question on platforms, the component can be relied on if the
>>> component's licence terms do not affect the Apache product's licensing. For
>>> example, using a GPL'ed tool during the build is OK.
>>> ""
>>>
>>> I'd prefer not to require a CLI option that requires a user to
>>> proactively enable the use of libaio. The ASYNCIO journal is what we
>>> recommend, and one of the main reasons we get such good performance on
>>> persisted messages, for this reason it should be default. I agree with
>>> Hiram in that changing the defaults would hinder user experience, as the
>>> default configuration is now considerably slower. Out of the box
>>> configuration should in my opinion be as close to optimum as we can.
>>> Having a user read the documentation, understand what ASYNCIO is, what
>>> benefits it has and then make a decision to enable it, is more effort.
>>>
>>> Rather than go around in circles arguing whether this is against
>>> licensing policy or not, I will fire an email to legal now and get a
>>> definitive answer.
>>>
>>> Regards
>>> Martyn
>>>
>>> On 23/12/15 21:12, Hiram Chirino wrote:
>>>
>>>> I think the binary distro uses the libaio.so if it's installed in your
>>>> system. Since it's optional, the broker should still start up fine
>>>> even if libaio is not installed, but it wont get used either.
>>>>
>>>> On Wed, Dec 23, 2015 at 4:05 PM, Daniel Kulp <dk...@apache.org> wrote:
>>>>
>>>>> Question: If I grab Artemis 1.1.0 tarbal/zip and start up the broker
>>>>> “out of the box”, does it use libaio or not? If I specifically have to
>>>>> configure something (pass a flag, edit a config file, etc…) to enable use
>>>>> if the LGPL library, then fine. However, if it’s something that occurs
>>>>> completely automatically without the user even knowing that it’s occurring,
>>>>> then I have a major problem with it. It needs to be something that the
>>>>> user has to explicitly CHOOSE to use.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>> On Dec 23, 2015, at 2:02 PM, Clebert Suconic <
>>>>>> clebert.suconic@gmail.com> wrote:
>>>>>>
>>>>>> also, there has also been questions about it during the donation
>>>>>> process.. licenses reviewed.. etc.. so I don't think we need to open a
>>>>>> new discussions over this. the binary inclusion on the source was
>>>>>> something that was fixed now.
>>>>>>
>>>>>> The dependency on libaio on the C code is through through dynamic
>>>>>> linked library, and is the same as any C code depending on libc or
>>>>>> gcc.
>>>>>>
>>>>>> On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
>>>>>> <cl...@gmail.com> wrote:
>>>>>>
>>>>>>> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament <
>>>>>>> johndament@apache.org> wrote:
>>>>>>>
>>>>>>>> Just wondering, does anyone plan to raise the LGPL question w/ legal
>>>>>>>> discuss? If we're waiting for the new year to do the next release,
>>>>>>>> would
>>>>>>>> be good to at least start the discussion.
>>>>>>>>
>>>>>>>
>>>>>>> We had such discussion long ago with legal. I couldn't find that
>>>>>>> email
>>>>>>> on my inbox but we specifically asked questions about it. We were ok
>>>>>>> as I remember. Maybe someone else (Martyn?) will have it on their
>>>>>>> inboxes. For that reason I don't want to go over the same issue we
>>>>>>> had
>>>>>>> asked before.
>>>>>>>
>>>>>>> The use of libaio is optional anyways and the system works as
>>>>>>> expected. what also covers other questions we had here on this
>>>>>>> thread.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Clebert Suconic
>>>>>>
>>>>> --
>>>>> Daniel Kulp
>>>>> dkulp@apache.org - http://dankulp.com/blog
>>>>> Talend Community Coder - http://coders.talend.com
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
Re: [VOTE] Apache Artemis 1.2.0
Posted by Martyn Taylor <mt...@redhat.com>.
All,
Re: The legal issues with the use of LibAIO.
The response from apache-legal is that the use of LibAIO in the context
of Apache Artemis is OK and does not pose any legal concerns. I realise
there is an on going side discussion regarding legal documentation and
perhaps contradictions between legal stances on Artemis and other
projects. But, given we've had the OK from several board members, I am
keen to go ahead and cut the next RC.
The legal discussion thread can be found here:
https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201512.mbox/%3C567BDDC1.8060805@redhat.com%3E
The next RC will have addressed the issues with binary inclusions in the
src release and also the great usability feedback provided by Claus
Ibsen. It should be with you very soon.
Regards
Martyn
On 24/12/15 12:01, Martyn Taylor wrote:
> I have sent an email to the legal-discuss describing the issue. Please
> follow the thread at the legal-discuss list.
>
> On 24/12/15 11:15, Martyn Taylor wrote:
>> I do not see what the issue is here. We are not *distributing* any
>> LGPL licensed library. We simply use it, if it is available. As
>> Hiram said, how does this differ from relying on bash or win32?
>>
>> To quote the legal docs: http://www.apache.org/legal/resolved.html
>>
>> ""
>> CAN APACHE PROJECTS RELY ON COMPONENTS UNDER PROHIBITED LICENSES?¶
>> <http://www.apache.org/legal/resolved.html#prohibited>
>>
>> Apache projects cannot distribute any such components. As with the
>> previous question on platforms, the component can be relied on if the
>> component's licence terms do not affect the Apache product's
>> licensing. For example, using a GPL'ed tool during the build is OK.
>> ""
>>
>> I'd prefer not to require a CLI option that requires a user to
>> proactively enable the use of libaio. The ASYNCIO journal is what we
>> recommend, and one of the main reasons we get such good performance
>> on persisted messages, for this reason it should be default. I agree
>> with Hiram in that changing the defaults would hinder user
>> experience, as the default configuration is now considerably slower.
>> Out of the box configuration should in my opinion be as close to
>> optimum as we can. Having a user read the documentation, understand
>> what ASYNCIO is, what benefits it has and then make a decision to
>> enable it, is more effort.
>>
>> Rather than go around in circles arguing whether this is against
>> licensing policy or not, I will fire an email to legal now and get a
>> definitive answer.
>>
>> Regards
>> Martyn
>>
>> On 23/12/15 21:12, Hiram Chirino wrote:
>>> I think the binary distro uses the libaio.so if it's installed in your
>>> system. Since it's optional, the broker should still start up fine
>>> even if libaio is not installed, but it wont get used either.
>>>
>>> On Wed, Dec 23, 2015 at 4:05 PM, Daniel Kulp <dk...@apache.org> wrote:
>>>> Question: If I grab Artemis 1.1.0 tarbal/zip and start up the
>>>> broker “out of the box”, does it use libaio or not? If I
>>>> specifically have to configure something (pass a flag, edit a
>>>> config file, etc…) to enable use if the LGPL library, then fine.
>>>> However, if it’s something that occurs completely automatically
>>>> without the user even knowing that it’s occurring, then I have a
>>>> major problem with it. It needs to be something that the user has
>>>> to explicitly CHOOSE to use.
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>>> On Dec 23, 2015, at 2:02 PM, Clebert Suconic
>>>>> <cl...@gmail.com> wrote:
>>>>>
>>>>> also, there has also been questions about it during the donation
>>>>> process.. licenses reviewed.. etc.. so I don't think we need to
>>>>> open a
>>>>> new discussions over this. the binary inclusion on the source was
>>>>> something that was fixed now.
>>>>>
>>>>> The dependency on libaio on the C code is through through dynamic
>>>>> linked library, and is the same as any C code depending on libc or
>>>>> gcc.
>>>>>
>>>>> On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
>>>>> <cl...@gmail.com> wrote:
>>>>>> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament
>>>>>> <jo...@apache.org> wrote:
>>>>>>> Just wondering, does anyone plan to raise the LGPL question w/
>>>>>>> legal
>>>>>>> discuss? If we're waiting for the new year to do the next
>>>>>>> release, would
>>>>>>> be good to at least start the discussion.
>>>>>>
>>>>>> We had such discussion long ago with legal. I couldn't find that
>>>>>> email
>>>>>> on my inbox but we specifically asked questions about it. We were ok
>>>>>> as I remember. Maybe someone else (Martyn?) will have it on their
>>>>>> inboxes. For that reason I don't want to go over the same issue
>>>>>> we had
>>>>>> asked before.
>>>>>>
>>>>>> The use of libaio is optional anyways and the system works as
>>>>>> expected. what also covers other questions we had here on this
>>>>>> thread.
>>>>>
>>>>>
>>>>> --
>>>>> Clebert Suconic
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org - http://dankulp.com/blog
>>>> Talend Community Coder - http://coders.talend.com
>>>>
>>>
>>>
>>
>>
>
Re: [VOTE] Apache Artemis 1.2.0
Posted by Martyn Taylor <mt...@redhat.com>.
I have sent an email to the legal-discuss describing the issue. Please
follow the thread at the legal-discuss list.
On 24/12/15 11:15, Martyn Taylor wrote:
> I do not see what the issue is here. We are not *distributing* any
> LGPL licensed library. We simply use it, if it is available. As Hiram
> said, how does this differ from relying on bash or win32?
>
> To quote the legal docs: http://www.apache.org/legal/resolved.html
>
> ""
> CAN APACHE PROJECTS RELY ON COMPONENTS UNDER PROHIBITED LICENSES?¶
> <http://www.apache.org/legal/resolved.html#prohibited>
>
> Apache projects cannot distribute any such components. As with the
> previous question on platforms, the component can be relied on if the
> component's licence terms do not affect the Apache product's
> licensing. For example, using a GPL'ed tool during the build is OK.
> ""
>
> I'd prefer not to require a CLI option that requires a user to
> proactively enable the use of libaio. The ASYNCIO journal is what we
> recommend, and one of the main reasons we get such good performance on
> persisted messages, for this reason it should be default. I agree
> with Hiram in that changing the defaults would hinder user experience,
> as the default configuration is now considerably slower. Out of the
> box configuration should in my opinion be as close to optimum as we
> can. Having a user read the documentation, understand what ASYNCIO
> is, what benefits it has and then make a decision to enable it, is
> more effort.
>
> Rather than go around in circles arguing whether this is against
> licensing policy or not, I will fire an email to legal now and get a
> definitive answer.
>
> Regards
> Martyn
>
> On 23/12/15 21:12, Hiram Chirino wrote:
>> I think the binary distro uses the libaio.so if it's installed in your
>> system. Since it's optional, the broker should still start up fine
>> even if libaio is not installed, but it wont get used either.
>>
>> On Wed, Dec 23, 2015 at 4:05 PM, Daniel Kulp <dk...@apache.org> wrote:
>>> Question: If I grab Artemis 1.1.0 tarbal/zip and start up the broker
>>> “out of the box”, does it use libaio or not? If I specifically have
>>> to configure something (pass a flag, edit a config file, etc…) to
>>> enable use if the LGPL library, then fine. However, if it’s
>>> something that occurs completely automatically without the user even
>>> knowing that it’s occurring, then I have a major problem with it.
>>> It needs to be something that the user has to explicitly CHOOSE to use.
>>>
>>> Dan
>>>
>>>
>>>
>>>> On Dec 23, 2015, at 2:02 PM, Clebert Suconic
>>>> <cl...@gmail.com> wrote:
>>>>
>>>> also, there has also been questions about it during the donation
>>>> process.. licenses reviewed.. etc.. so I don't think we need to open a
>>>> new discussions over this. the binary inclusion on the source was
>>>> something that was fixed now.
>>>>
>>>> The dependency on libaio on the C code is through through dynamic
>>>> linked library, and is the same as any C code depending on libc or
>>>> gcc.
>>>>
>>>> On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
>>>> <cl...@gmail.com> wrote:
>>>>> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament
>>>>> <jo...@apache.org> wrote:
>>>>>> Just wondering, does anyone plan to raise the LGPL question w/ legal
>>>>>> discuss? If we're waiting for the new year to do the next
>>>>>> release, would
>>>>>> be good to at least start the discussion.
>>>>>
>>>>> We had such discussion long ago with legal. I couldn't find that
>>>>> email
>>>>> on my inbox but we specifically asked questions about it. We were ok
>>>>> as I remember. Maybe someone else (Martyn?) will have it on their
>>>>> inboxes. For that reason I don't want to go over the same issue we
>>>>> had
>>>>> asked before.
>>>>>
>>>>> The use of libaio is optional anyways and the system works as
>>>>> expected. what also covers other questions we had here on this
>>>>> thread.
>>>>
>>>>
>>>> --
>>>> Clebert Suconic
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>>
>>
>>
>
>
Re: [VOTE] Apache Artemis 1.2.0
Posted by Martyn Taylor <mt...@redhat.com>.
I do not see what the issue is here. We are not *distributing* any LGPL
licensed library. We simply use it, if it is available. As Hiram said,
how does this differ from relying on bash or win32?
To quote the legal docs: http://www.apache.org/legal/resolved.html
""
CAN APACHE PROJECTS RELY ON COMPONENTS UNDER PROHIBITED LICENSES?¶
<http://www.apache.org/legal/resolved.html#prohibited>
Apache projects cannot distribute any such components. As with the
previous question on platforms, the component can be relied on if the
component's licence terms do not affect the Apache product's licensing.
For example, using a GPL'ed tool during the build is OK.
""
I'd prefer not to require a CLI option that requires a user to
proactively enable the use of libaio. The ASYNCIO journal is what we
recommend, and one of the main reasons we get such good performance on
persisted messages, for this reason it should be default. I agree with
Hiram in that changing the defaults would hinder user experience, as the
default configuration is now considerably slower. Out of the box
configuration should in my opinion be as close to optimum as we can.
Having a user read the documentation, understand what ASYNCIO is, what
benefits it has and then make a decision to enable it, is more effort.
Rather than go around in circles arguing whether this is against
licensing policy or not, I will fire an email to legal now and get a
definitive answer.
Regards
Martyn
On 23/12/15 21:12, Hiram Chirino wrote:
> I think the binary distro uses the libaio.so if it's installed in your
> system. Since it's optional, the broker should still start up fine
> even if libaio is not installed, but it wont get used either.
>
> On Wed, Dec 23, 2015 at 4:05 PM, Daniel Kulp <dk...@apache.org> wrote:
>> Question: If I grab Artemis 1.1.0 tarbal/zip and start up the broker “out of the box”, does it use libaio or not? If I specifically have to configure something (pass a flag, edit a config file, etc…) to enable use if the LGPL library, then fine. However, if it’s something that occurs completely automatically without the user even knowing that it’s occurring, then I have a major problem with it. It needs to be something that the user has to explicitly CHOOSE to use.
>>
>> Dan
>>
>>
>>
>>> On Dec 23, 2015, at 2:02 PM, Clebert Suconic <cl...@gmail.com> wrote:
>>>
>>> also, there has also been questions about it during the donation
>>> process.. licenses reviewed.. etc.. so I don't think we need to open a
>>> new discussions over this. the binary inclusion on the source was
>>> something that was fixed now.
>>>
>>> The dependency on libaio on the C code is through through dynamic
>>> linked library, and is the same as any C code depending on libc or
>>> gcc.
>>>
>>> On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
>>> <cl...@gmail.com> wrote:
>>>> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament <jo...@apache.org> wrote:
>>>>> Just wondering, does anyone plan to raise the LGPL question w/ legal
>>>>> discuss? If we're waiting for the new year to do the next release, would
>>>>> be good to at least start the discussion.
>>>>
>>>> We had such discussion long ago with legal. I couldn't find that email
>>>> on my inbox but we specifically asked questions about it. We were ok
>>>> as I remember. Maybe someone else (Martyn?) will have it on their
>>>> inboxes. For that reason I don't want to go over the same issue we had
>>>> asked before.
>>>>
>>>> The use of libaio is optional anyways and the system works as
>>>> expected. what also covers other questions we had here on this thread.
>>>
>>>
>>> --
>>> Clebert Suconic
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>
>
Re: [VOTE] Apache Artemis 1.2.0
Posted by Hiram Chirino <hi...@hiramchirino.com>.
I think the binary distro uses the libaio.so if it's installed in your
system. Since it's optional, the broker should still start up fine
even if libaio is not installed, but it wont get used either.
On Wed, Dec 23, 2015 at 4:05 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> Question: If I grab Artemis 1.1.0 tarbal/zip and start up the broker “out of the box”, does it use libaio or not? If I specifically have to configure something (pass a flag, edit a config file, etc…) to enable use if the LGPL library, then fine. However, if it’s something that occurs completely automatically without the user even knowing that it’s occurring, then I have a major problem with it. It needs to be something that the user has to explicitly CHOOSE to use.
>
> Dan
>
>
>
>> On Dec 23, 2015, at 2:02 PM, Clebert Suconic <cl...@gmail.com> wrote:
>>
>> also, there has also been questions about it during the donation
>> process.. licenses reviewed.. etc.. so I don't think we need to open a
>> new discussions over this. the binary inclusion on the source was
>> something that was fixed now.
>>
>> The dependency on libaio on the C code is through through dynamic
>> linked library, and is the same as any C code depending on libc or
>> gcc.
>>
>> On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
>> <cl...@gmail.com> wrote:
>>> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament <jo...@apache.org> wrote:
>>>> Just wondering, does anyone plan to raise the LGPL question w/ legal
>>>> discuss? If we're waiting for the new year to do the next release, would
>>>> be good to at least start the discussion.
>>>
>>>
>>> We had such discussion long ago with legal. I couldn't find that email
>>> on my inbox but we specifically asked questions about it. We were ok
>>> as I remember. Maybe someone else (Martyn?) will have it on their
>>> inboxes. For that reason I don't want to go over the same issue we had
>>> asked before.
>>>
>>> The use of libaio is optional anyways and the system works as
>>> expected. what also covers other questions we had here on this thread.
>>
>>
>>
>> --
>> Clebert Suconic
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
--
Hiram Chirino
Engineering | Red Hat, Inc.
hchirino@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
Re: [VOTE] Apache Artemis 1.2.0
Posted by Hiram Chirino <hi...@hiramchirino.com>.
My bad. Missread johns original message. Thought we was saying have prompt
to enable libaio. Apologies.
On Wednesday, December 23, 2015, Daniel Kulp <dk...@apache.org> wrote:
>
> > On Dec 23, 2015, at 6:34 PM, Hiram Chirino <hiram@hiramchirino.com
> <javascript:;>> wrote:
> >
> > -1 that seems silly. There is no legal reason to do that and it gives our
> > users a worse experience out of the box.
>
> Giving our users the information they would need to make it perform better
> is giving them a worse experience?
>
> Dan
>
>
>
> >
> > On Wednesday, December 23, 2015, John D. Ament <johndament@apache.org
> <javascript:;>>
> > wrote:
> >
> >> +1 for a prompt on broker creation.
> >>
> >> It could even include a prompt, say "No libaio detected, to make your
> >> Artemis server faster please install libaio and {do necessary step to
> >> enable in broker}" but if it is installed, just prompt/given flag.
> >>
> >> John
> >>
> >> On Wed, Dec 23, 2015 at 5:07 PM Daniel Kulp <dkulp@apache.org
> <javascript:;>
> >> <javascript:;>> wrote:
> >>
> >>>
> >>>> On Dec 23, 2015, at 4:55 PM, Andy Taylor <andy.tayls67@gmail.com
> <javascript:;>
> >> <javascript:;>> wrote:
> >>>> I Guess it depends on what they mean by enabled. If the user has to
> >>>> explicitly install it then to me it's optional. Saying that if it's
> >>>> installed by default on the OS you could argue the opposite.
> >>>
> >>> The issue with the is that the user may not even know if they have it
> >>> installed or not. For example, on my two gentoo linux boxes, one has
> >> it
> >>> installed and one doesn’t. I have no idea why the one that has it
> >>> installed has it. With the package management and such, something I
> >>> installed there some time in the past must have caused it to install.
> >>> (likely mysql)
> >>>
> >>>> We could change the cli to prompt for a choice at create time.
> >>>
> >>> That would certainly work.
> >>>
> >>> Dan
> >>>
> >>>
> >>>
> >>>> On Wed, 23 Dec 2015 21:41 Daniel Kulp <dkulp@apache.org
> <javascript:;> <javascript:;>>
> >> wrote:
> >>>>
> >>>>>
> >>>>>> On Dec 23, 2015, at 4:07 PM, John D. Ament <johndament@apache.org
> <javascript:;>
> >> <javascript:;>>
> >>>>> wrote:
> >>>>>>
> >>>>>> Are you referring to the bin or src distribution?
> >>>>>
> >>>>> Kind of both…
> >>>>>
> >>>>> By removing the binary from the src distribution, that covers that
> >> case.
> >>>>> The user would have to cd into the appropriate directory and
> >> explicitly
> >>>>> run the “make” or whatever to build the binary. It’s an explicit
> >>> choice
> >>>>> they make. Thus, I’m completely OK with that now.
> >>>>>
> >>>>>
> >>>>> The bin distribution is still an issue. If the default was to not
> >> use
> >>>>> the libaio at all unless the user either edited a config file to
> >> enable
> >>> it
> >>>>> or pass a command line flag or similar to take explicit action, I’d
> be
> >>> OK
> >>>>> there as well. The new wording on the legal pages is completely
> >>>>> confusing. The original suggested wording in:
> >>>>> https://issues.apache.org/jira/browse/LEGAL-54
> >>>>> makes so much more sense:
> >>>>>
> >>>>> "However, projects may use LGPL licensed works in optional features
> >> that
> >>>>> are not enabled by default.”
> >>>>>
> >>>>>
> >>>>> Dan
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> On Wed, Dec 23, 2015 at 4:05 PM Daniel Kulp <dkulp@apache.org
> <javascript:;>
> >> <javascript:;>> wrote:
> >>>>>>
> >>>>>>>
> >>>>>>> Question: If I grab Artemis 1.1.0 tarbal/zip and start up the
> broker
> >>>>> “out
> >>>>>>> of the box”, does it use libaio or not? If I specifically have to
> >>>>>>> configure something (pass a flag, edit a config file, etc…) to
> >> enable
> >>>>> use
> >>>>>>> if the LGPL library, then fine. However, if it’s something that
> >>>>> occurs
> >>>>>>> completely automatically without the user even knowing that it’s
> >>>>> occurring,
> >>>>>>> then I have a major problem with it. It needs to be something that
> >>> the
> >>>>>>> user has to explicitly CHOOSE to use.
> >>>>>>>
> >>>>>>> Dan
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Dec 23, 2015, at 2:02 PM, Clebert Suconic <
> >>>>> clebert.suconic@gmail.com <javascript:;> <javascript:;>>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> also, there has also been questions about it during the donation
> >>>>>>>> process.. licenses reviewed.. etc.. so I don't think we need to
> >> open
> >>> a
> >>>>>>>> new discussions over this. the binary inclusion on the source was
> >>>>>>>> something that was fixed now.
> >>>>>>>>
> >>>>>>>> The dependency on libaio on the C code is through through dynamic
> >>>>>>>> linked library, and is the same as any C code depending on libc or
> >>>>>>>> gcc.
> >>>>>>>>
> >>>>>>>> On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
> >>>>>>>> <clebert.suconic@gmail.com <javascript:;> <javascript:;>> wrote:
> >>>>>>>>> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament <
> >>> johndament@apache.org <javascript:;> <javascript:;>
> >>>>>>
> >>>>>>> wrote:
> >>>>>>>>>> Just wondering, does anyone plan to raise the LGPL question w/
> >>> legal
> >>>>>>>>>> discuss? If we're waiting for the new year to do the next
> >> release,
> >>>>>>> would
> >>>>>>>>>> be good to at least start the discussion.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> We had such discussion long ago with legal. I couldn't find that
> >>> email
> >>>>>>>>> on my inbox but we specifically asked questions about it. We were
> >> ok
> >>>>>>>>> as I remember. Maybe someone else (Martyn?) will have it on their
> >>>>>>>>> inboxes. For that reason I don't want to go over the same issue
> we
> >>> had
> >>>>>>>>> asked before.
> >>>>>>>>>
> >>>>>>>>> The use of libaio is optional anyways and the system works as
> >>>>>>>>> expected. what also covers other questions we had here on this
> >>> thread.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Clebert Suconic
> >>>>>>>
> >>>>>>> --
> >>>>>>> Daniel Kulp
> >>>>>>> dkulp@apache.org <javascript:;> <javascript:;> -
> http://dankulp.com/blog
> >>>>>>> Talend Community Coder - http://coders.talend.com
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>> --
> >>>>> Daniel Kulp
> >>>>> dkulp@apache.org <javascript:;> <javascript:;> -
> http://dankulp.com/blog
> >>>>> Talend Community Coder - http://coders.talend.com
> >>>>>
> >>>>>
> >>>
> >>> --
> >>> Daniel Kulp
> >>> dkulp@apache.org <javascript:;> <javascript:;> -
> http://dankulp.com/blog
> >>> Talend Community Coder - http://coders.talend.com
> >>>
> >>>
> >>
> >
> >
> > --
> > Hiram Chirino
> > Engineering | Red Hat, Inc.
> > hchirino@redhat.com <javascript:;> | fusesource.com | redhat.com
> > skype: hiramchirino | twitter: @hiramchirino
>
> --
> Daniel Kulp
> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
--
Hiram Chirino
Engineering | Red Hat, Inc.
hchirino@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
Re: [VOTE] Apache Artemis 1.2.0
Posted by Andy Taylor <an...@gmail.com>.
As John Says, lets run it past legal, if they are happy that what is
shipped is ok then lets leave as is, if not, then make it an optional
(as in it takes a flag/explicit) choice at create time.
John, how do we do this?
On 24/12/15 00:25, Daniel Kulp wrote:
>
>> On Dec 23, 2015, at 6:34 PM, Hiram Chirino <hi...@hiramchirino.com> wrote:
>>
>> -1 that seems silly. There is no legal reason to do that and it gives our
>> users a worse experience out of the box.
>
> Giving our users the information they would need to make it perform better is giving them a worse experience?
>
> Dan
>
>
>
>>
>> On Wednesday, December 23, 2015, John D. Ament <jo...@apache.org>
>> wrote:
>>
>>> +1 for a prompt on broker creation.
>>>
>>> It could even include a prompt, say "No libaio detected, to make your
>>> Artemis server faster please install libaio and {do necessary step to
>>> enable in broker}" but if it is installed, just prompt/given flag.
>>>
>>> John
>>>
>>> On Wed, Dec 23, 2015 at 5:07 PM Daniel Kulp <dkulp@apache.org
>>> <javascript:;>> wrote:
>>>
>>>>
>>>>> On Dec 23, 2015, at 4:55 PM, Andy Taylor <andy.tayls67@gmail.com
>>> <javascript:;>> wrote:
>>>>> I Guess it depends on what they mean by enabled. If the user has to
>>>>> explicitly install it then to me it's optional. Saying that if it's
>>>>> installed by default on the OS you could argue the opposite.
>>>>
>>>> The issue with the is that the user may not even know if they have it
>>>> installed or not. For example, on my two gentoo linux boxes, one has
>>> it
>>>> installed and one doesn’t. I have no idea why the one that has it
>>>> installed has it. With the package management and such, something I
>>>> installed there some time in the past must have caused it to install.
>>>> (likely mysql)
>>>>
>>>>> We could change the cli to prompt for a choice at create time.
>>>>
>>>> That would certainly work.
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>>> On Wed, 23 Dec 2015 21:41 Daniel Kulp <dkulp@apache.org <javascript:;>>
>>> wrote:
>>>>>
>>>>>>
>>>>>>> On Dec 23, 2015, at 4:07 PM, John D. Ament <johndament@apache.org
>>> <javascript:;>>
>>>>>> wrote:
>>>>>>>
>>>>>>> Are you referring to the bin or src distribution?
>>>>>>
>>>>>> Kind of both…
>>>>>>
>>>>>> By removing the binary from the src distribution, that covers that
>>> case.
>>>>>> The user would have to cd into the appropriate directory and
>>> explicitly
>>>>>> run the “make” or whatever to build the binary. It’s an explicit
>>>> choice
>>>>>> they make. Thus, I’m completely OK with that now.
>>>>>>
>>>>>>
>>>>>> The bin distribution is still an issue. If the default was to not
>>> use
>>>>>> the libaio at all unless the user either edited a config file to
>>> enable
>>>> it
>>>>>> or pass a command line flag or similar to take explicit action, I’d be
>>>> OK
>>>>>> there as well. The new wording on the legal pages is completely
>>>>>> confusing. The original suggested wording in:
>>>>>> https://issues.apache.org/jira/browse/LEGAL-54
>>>>>> makes so much more sense:
>>>>>>
>>>>>> "However, projects may use LGPL licensed works in optional features
>>> that
>>>>>> are not enabled by default.”
>>>>>>
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Wed, Dec 23, 2015 at 4:05 PM Daniel Kulp <dkulp@apache.org
>>> <javascript:;>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Question: If I grab Artemis 1.1.0 tarbal/zip and start up the broker
>>>>>> “out
>>>>>>>> of the box”, does it use libaio or not? If I specifically have to
>>>>>>>> configure something (pass a flag, edit a config file, etc…) to
>>> enable
>>>>>> use
>>>>>>>> if the LGPL library, then fine. However, if it’s something that
>>>>>> occurs
>>>>>>>> completely automatically without the user even knowing that it’s
>>>>>> occurring,
>>>>>>>> then I have a major problem with it. It needs to be something that
>>>> the
>>>>>>>> user has to explicitly CHOOSE to use.
>>>>>>>>
>>>>>>>> Dan
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Dec 23, 2015, at 2:02 PM, Clebert Suconic <
>>>>>> clebert.suconic@gmail.com <javascript:;>>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> also, there has also been questions about it during the donation
>>>>>>>>> process.. licenses reviewed.. etc.. so I don't think we need to
>>> open
>>>> a
>>>>>>>>> new discussions over this. the binary inclusion on the source was
>>>>>>>>> something that was fixed now.
>>>>>>>>>
>>>>>>>>> The dependency on libaio on the C code is through through dynamic
>>>>>>>>> linked library, and is the same as any C code depending on libc or
>>>>>>>>> gcc.
>>>>>>>>>
>>>>>>>>> On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
>>>>>>>>> <clebert.suconic@gmail.com <javascript:;>> wrote:
>>>>>>>>>> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament <
>>>> johndament@apache.org <javascript:;>
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>>>> Just wondering, does anyone plan to raise the LGPL question w/
>>>> legal
>>>>>>>>>>> discuss? If we're waiting for the new year to do the next
>>> release,
>>>>>>>> would
>>>>>>>>>>> be good to at least start the discussion.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> We had such discussion long ago with legal. I couldn't find that
>>>> email
>>>>>>>>>> on my inbox but we specifically asked questions about it. We were
>>> ok
>>>>>>>>>> as I remember. Maybe someone else (Martyn?) will have it on their
>>>>>>>>>> inboxes. For that reason I don't want to go over the same issue we
>>>> had
>>>>>>>>>> asked before.
>>>>>>>>>>
>>>>>>>>>> The use of libaio is optional anyways and the system works as
>>>>>>>>>> expected. what also covers other questions we had here on this
>>>> thread.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Clebert Suconic
>>>>>>>>
>>>>>>>> --
>>>>>>>> Daniel Kulp
>>>>>>>> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
>>>>>>>> Talend Community Coder - http://coders.talend.com
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Daniel Kulp
>>>>>> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
>>>>>> Talend Community Coder - http://coders.talend.com
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
>>>> Talend Community Coder - http://coders.talend.com
>>>>
>>>>
>>>
>>
>>
>> --
>> Hiram Chirino
>> Engineering | Red Hat, Inc.
>> hchirino@redhat.com | fusesource.com | redhat.com
>> skype: hiramchirino | twitter: @hiramchirino
>
Re: [VOTE] Apache Artemis 1.2.0
Posted by Clebert Suconic <cl...@gmail.com>.
anyway guys.. it's been a great year... lets enjoy the holidays..
chill out a bit..
It's been a great year and I'm happy to be part of this community.
Happy holidays you all.. I'm out :)
On Wed, Dec 23, 2015 at 7:30 PM, Clebert Suconic
<cl...@gmail.com> wrote:
>> Giving our users the information they would need to make it perform better is giving them a worse experience?
>
>
> ok.. there's no technical or legal point about it.. but if that
> settles the discussion lets do it. I don't want to spend more time
> writing emails, talking to legal than I would on write 10 lines of
> code to settle this.
--
Clebert Suconic
Re: [VOTE] Apache Artemis 1.2.0
Posted by Clebert Suconic <cl...@gmail.com>.
> Giving our users the information they would need to make it perform better is giving them a worse experience?
ok.. there's no technical or legal point about it.. but if that
settles the discussion lets do it. I don't want to spend more time
writing emails, talking to legal than I would on write 10 lines of
code to settle this.
Re: [VOTE] Apache Artemis 1.2.0
Posted by Daniel Kulp <dk...@apache.org>.
> On Dec 23, 2015, at 6:34 PM, Hiram Chirino <hi...@hiramchirino.com> wrote:
>
> -1 that seems silly. There is no legal reason to do that and it gives our
> users a worse experience out of the box.
Giving our users the information they would need to make it perform better is giving them a worse experience?
Dan
>
> On Wednesday, December 23, 2015, John D. Ament <jo...@apache.org>
> wrote:
>
>> +1 for a prompt on broker creation.
>>
>> It could even include a prompt, say "No libaio detected, to make your
>> Artemis server faster please install libaio and {do necessary step to
>> enable in broker}" but if it is installed, just prompt/given flag.
>>
>> John
>>
>> On Wed, Dec 23, 2015 at 5:07 PM Daniel Kulp <dkulp@apache.org
>> <javascript:;>> wrote:
>>
>>>
>>>> On Dec 23, 2015, at 4:55 PM, Andy Taylor <andy.tayls67@gmail.com
>> <javascript:;>> wrote:
>>>> I Guess it depends on what they mean by enabled. If the user has to
>>>> explicitly install it then to me it's optional. Saying that if it's
>>>> installed by default on the OS you could argue the opposite.
>>>
>>> The issue with the is that the user may not even know if they have it
>>> installed or not. For example, on my two gentoo linux boxes, one has
>> it
>>> installed and one doesn’t. I have no idea why the one that has it
>>> installed has it. With the package management and such, something I
>>> installed there some time in the past must have caused it to install.
>>> (likely mysql)
>>>
>>>> We could change the cli to prompt for a choice at create time.
>>>
>>> That would certainly work.
>>>
>>> Dan
>>>
>>>
>>>
>>>> On Wed, 23 Dec 2015 21:41 Daniel Kulp <dkulp@apache.org <javascript:;>>
>> wrote:
>>>>
>>>>>
>>>>>> On Dec 23, 2015, at 4:07 PM, John D. Ament <johndament@apache.org
>> <javascript:;>>
>>>>> wrote:
>>>>>>
>>>>>> Are you referring to the bin or src distribution?
>>>>>
>>>>> Kind of both…
>>>>>
>>>>> By removing the binary from the src distribution, that covers that
>> case.
>>>>> The user would have to cd into the appropriate directory and
>> explicitly
>>>>> run the “make” or whatever to build the binary. It’s an explicit
>>> choice
>>>>> they make. Thus, I’m completely OK with that now.
>>>>>
>>>>>
>>>>> The bin distribution is still an issue. If the default was to not
>> use
>>>>> the libaio at all unless the user either edited a config file to
>> enable
>>> it
>>>>> or pass a command line flag or similar to take explicit action, I’d be
>>> OK
>>>>> there as well. The new wording on the legal pages is completely
>>>>> confusing. The original suggested wording in:
>>>>> https://issues.apache.org/jira/browse/LEGAL-54
>>>>> makes so much more sense:
>>>>>
>>>>> "However, projects may use LGPL licensed works in optional features
>> that
>>>>> are not enabled by default.”
>>>>>
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> On Wed, Dec 23, 2015 at 4:05 PM Daniel Kulp <dkulp@apache.org
>> <javascript:;>> wrote:
>>>>>>
>>>>>>>
>>>>>>> Question: If I grab Artemis 1.1.0 tarbal/zip and start up the broker
>>>>> “out
>>>>>>> of the box”, does it use libaio or not? If I specifically have to
>>>>>>> configure something (pass a flag, edit a config file, etc…) to
>> enable
>>>>> use
>>>>>>> if the LGPL library, then fine. However, if it’s something that
>>>>> occurs
>>>>>>> completely automatically without the user even knowing that it’s
>>>>> occurring,
>>>>>>> then I have a major problem with it. It needs to be something that
>>> the
>>>>>>> user has to explicitly CHOOSE to use.
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Dec 23, 2015, at 2:02 PM, Clebert Suconic <
>>>>> clebert.suconic@gmail.com <javascript:;>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> also, there has also been questions about it during the donation
>>>>>>>> process.. licenses reviewed.. etc.. so I don't think we need to
>> open
>>> a
>>>>>>>> new discussions over this. the binary inclusion on the source was
>>>>>>>> something that was fixed now.
>>>>>>>>
>>>>>>>> The dependency on libaio on the C code is through through dynamic
>>>>>>>> linked library, and is the same as any C code depending on libc or
>>>>>>>> gcc.
>>>>>>>>
>>>>>>>> On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
>>>>>>>> <clebert.suconic@gmail.com <javascript:;>> wrote:
>>>>>>>>> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament <
>>> johndament@apache.org <javascript:;>
>>>>>>
>>>>>>> wrote:
>>>>>>>>>> Just wondering, does anyone plan to raise the LGPL question w/
>>> legal
>>>>>>>>>> discuss? If we're waiting for the new year to do the next
>> release,
>>>>>>> would
>>>>>>>>>> be good to at least start the discussion.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We had such discussion long ago with legal. I couldn't find that
>>> email
>>>>>>>>> on my inbox but we specifically asked questions about it. We were
>> ok
>>>>>>>>> as I remember. Maybe someone else (Martyn?) will have it on their
>>>>>>>>> inboxes. For that reason I don't want to go over the same issue we
>>> had
>>>>>>>>> asked before.
>>>>>>>>>
>>>>>>>>> The use of libaio is optional anyways and the system works as
>>>>>>>>> expected. what also covers other questions we had here on this
>>> thread.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Clebert Suconic
>>>>>>>
>>>>>>> --
>>>>>>> Daniel Kulp
>>>>>>> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
>>>>>>> Talend Community Coder - http://coders.talend.com
>>>>>>>
>>>>>>>
>>>>>
>>>>> --
>>>>> Daniel Kulp
>>>>> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
>>>>> Talend Community Coder - http://coders.talend.com
>>>>>
>>>>>
>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>>
>>>
>>
>
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> hchirino@redhat.com | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache Artemis 1.2.0
Posted by Clebert Suconic <cl...@gmail.com>.
> libaio is NOT installed by default on pretty much any of the linux
> “platforms" so I would have a hard time considering as a part of the
> platform.
linux AIO is part of the kernel. You have no choice over it if you are
using a regular distribution. (Unless you recompile the kernel without
it)
libaio, the wrapper is not. it would be possible to write syscalls
directly to the kernel and you would have no choice over it as long as
you are working on linux.
I don't want to reinvent the wheel though... the optional dependency,
checking if the system has the capability or not would be enough IMO.
(with the user having the choice to enable it or not).
Re: [VOTE] Apache Artemis 1.2.0
Posted by Hiram Chirino <hi...@hiramchirino.com>.
What's the diffence between one platform api like aio and another like
win32? They have about the same effect on our code. We can't distribute
their libs and they don't force us to change our licensing terms.
Btw the compiler you use has nothing to do with the libs you link against.
And most Linux apps link against glibc. It's just a platform API. Which the
official apache policy says there are no problems on linking against.
On Wednesday, December 23, 2015, Daniel Kulp <dk...@apache.org> wrote:
>
> > On Dec 23, 2015, at 6:45 PM, Clebert Suconic <clebert.suconic@gmail.com
> <javascript:;>> wrote:
> >
> >
> > Anyways, Saying you can't depend on anything LGPL is the same as
> > saying you can't depend on Linux or anything coming from Linux. for
> > instance Apache HTTP (the very first project that founded this
> > organization) would be breaking the apache license itself by using
> > libc. (Open the source code if you don't believe me).
> >
> > It's certainly not the case...as libc is a platform API.
>
> Except you can build HTTP on Linux and NOT depend on the gnu license
> libc. I can use clang as the compiler (or the intel compiler or ….) and
> not end up with a dependency on a LGPL library. If you have a non-LGPL
> version of libaio, then by all means, let’s use it.
>
> > libaio is also a platform API.
>
> libaio is NOT installed by default on pretty much any of the linux
> “platforms" so I would have a hard time considering as a part of the
> platform.
>
>
> --
> Daniel Kulp
> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
--
Hiram Chirino
Engineering | Red Hat, Inc.
hchirino@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
Re: [VOTE] Apache Artemis 1.2.0
Posted by Daniel Kulp <dk...@apache.org>.
> On Dec 23, 2015, at 6:45 PM, Clebert Suconic <cl...@gmail.com> wrote:
>
>
> Anyways, Saying you can't depend on anything LGPL is the same as
> saying you can't depend on Linux or anything coming from Linux. for
> instance Apache HTTP (the very first project that founded this
> organization) would be breaking the apache license itself by using
> libc. (Open the source code if you don't believe me).
>
> It's certainly not the case...as libc is a platform API.
Except you can build HTTP on Linux and NOT depend on the gnu license libc. I can use clang as the compiler (or the intel compiler or ….) and not end up with a dependency on a LGPL library. If you have a non-LGPL version of libaio, then by all means, let’s use it.
> libaio is also a platform API.
libaio is NOT installed by default on pretty much any of the linux “platforms" so I would have a hard time considering as a part of the platform.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache Artemis 1.2.0
Posted by Clebert Suconic <cl...@gmail.com>.
Let me explain what libaio is:
it's a wrapper that makes calls into the kernel.
if you for instance open libaio.c, this is the entire source code for
io_submit (the most used function):
io_syscall3(int, io_submit, io_submit, io_context_t, ctx, long, nr,
struct iocb **, iocbs)
See for yourself:
https://git.fedorahosted.org/cgit/libaio.git/log/
Open libaio.spec:
on the definition: This library, libaio, provides the Linux-native API
for async I/O.
Anyways, Saying you can't depend on anything LGPL is the same as
saying you can't depend on Linux or anything coming from Linux. for
instance Apache HTTP (the very first project that founded this
organization) would be breaking the apache license itself by using
libc. (Open the source code if you don't believe me).
It's certainly not the case...as libc is a platform API.
libaio is also a platform API.
hence the definition that HIram found...
Re: [VOTE] Apache Artemis 1.2.0
Posted by Hiram Chirino <hi...@hiramchirino.com>.
-1 that seems silly. There is no legal reason to do that and it gives our
users a worse experience out of the box.
On Wednesday, December 23, 2015, John D. Ament <jo...@apache.org>
wrote:
> +1 for a prompt on broker creation.
>
> It could even include a prompt, say "No libaio detected, to make your
> Artemis server faster please install libaio and {do necessary step to
> enable in broker}" but if it is installed, just prompt/given flag.
>
> John
>
> On Wed, Dec 23, 2015 at 5:07 PM Daniel Kulp <dkulp@apache.org
> <javascript:;>> wrote:
>
> >
> > > On Dec 23, 2015, at 4:55 PM, Andy Taylor <andy.tayls67@gmail.com
> <javascript:;>> wrote:
> > > I Guess it depends on what they mean by enabled. If the user has to
> > > explicitly install it then to me it's optional. Saying that if it's
> > > installed by default on the OS you could argue the opposite.
> >
> > The issue with the is that the user may not even know if they have it
> > installed or not. For example, on my two gentoo linux boxes, one has
> it
> > installed and one doesn’t. I have no idea why the one that has it
> > installed has it. With the package management and such, something I
> > installed there some time in the past must have caused it to install.
> > (likely mysql)
> >
> > > We could change the cli to prompt for a choice at create time.
> >
> > That would certainly work.
> >
> > Dan
> >
> >
> >
> > > On Wed, 23 Dec 2015 21:41 Daniel Kulp <dkulp@apache.org <javascript:;>>
> wrote:
> > >
> > >>
> > >>> On Dec 23, 2015, at 4:07 PM, John D. Ament <johndament@apache.org
> <javascript:;>>
> > >> wrote:
> > >>>
> > >>> Are you referring to the bin or src distribution?
> > >>
> > >> Kind of both…
> > >>
> > >> By removing the binary from the src distribution, that covers that
> case.
> > >> The user would have to cd into the appropriate directory and
> explicitly
> > >> run the “make” or whatever to build the binary. It’s an explicit
> > choice
> > >> they make. Thus, I’m completely OK with that now.
> > >>
> > >>
> > >> The bin distribution is still an issue. If the default was to not
> use
> > >> the libaio at all unless the user either edited a config file to
> enable
> > it
> > >> or pass a command line flag or similar to take explicit action, I’d be
> > OK
> > >> there as well. The new wording on the legal pages is completely
> > >> confusing. The original suggested wording in:
> > >> https://issues.apache.org/jira/browse/LEGAL-54
> > >> makes so much more sense:
> > >>
> > >> "However, projects may use LGPL licensed works in optional features
> that
> > >> are not enabled by default.”
> > >>
> > >>
> > >> Dan
> > >>
> > >>
> > >>
> > >>>
> > >>> On Wed, Dec 23, 2015 at 4:05 PM Daniel Kulp <dkulp@apache.org
> <javascript:;>> wrote:
> > >>>
> > >>>>
> > >>>> Question: If I grab Artemis 1.1.0 tarbal/zip and start up the broker
> > >> “out
> > >>>> of the box”, does it use libaio or not? If I specifically have to
> > >>>> configure something (pass a flag, edit a config file, etc…) to
> enable
> > >> use
> > >>>> if the LGPL library, then fine. However, if it’s something that
> > >> occurs
> > >>>> completely automatically without the user even knowing that it’s
> > >> occurring,
> > >>>> then I have a major problem with it. It needs to be something that
> > the
> > >>>> user has to explicitly CHOOSE to use.
> > >>>>
> > >>>> Dan
> > >>>>
> > >>>>
> > >>>>
> > >>>>> On Dec 23, 2015, at 2:02 PM, Clebert Suconic <
> > >> clebert.suconic@gmail.com <javascript:;>>
> > >>>> wrote:
> > >>>>>
> > >>>>> also, there has also been questions about it during the donation
> > >>>>> process.. licenses reviewed.. etc.. so I don't think we need to
> open
> > a
> > >>>>> new discussions over this. the binary inclusion on the source was
> > >>>>> something that was fixed now.
> > >>>>>
> > >>>>> The dependency on libaio on the C code is through through dynamic
> > >>>>> linked library, and is the same as any C code depending on libc or
> > >>>>> gcc.
> > >>>>>
> > >>>>> On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
> > >>>>> <clebert.suconic@gmail.com <javascript:;>> wrote:
> > >>>>>> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament <
> > johndament@apache.org <javascript:;>
> > >>>
> > >>>> wrote:
> > >>>>>>> Just wondering, does anyone plan to raise the LGPL question w/
> > legal
> > >>>>>>> discuss? If we're waiting for the new year to do the next
> release,
> > >>>> would
> > >>>>>>> be good to at least start the discussion.
> > >>>>>>
> > >>>>>>
> > >>>>>> We had such discussion long ago with legal. I couldn't find that
> > email
> > >>>>>> on my inbox but we specifically asked questions about it. We were
> ok
> > >>>>>> as I remember. Maybe someone else (Martyn?) will have it on their
> > >>>>>> inboxes. For that reason I don't want to go over the same issue we
> > had
> > >>>>>> asked before.
> > >>>>>>
> > >>>>>> The use of libaio is optional anyways and the system works as
> > >>>>>> expected. what also covers other questions we had here on this
> > thread.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>> Clebert Suconic
> > >>>>
> > >>>> --
> > >>>> Daniel Kulp
> > >>>> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
> > >>>> Talend Community Coder - http://coders.talend.com
> > >>>>
> > >>>>
> > >>
> > >> --
> > >> Daniel Kulp
> > >> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
> > >> Talend Community Coder - http://coders.talend.com
> > >>
> > >>
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org <javascript:;> - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
> >
>
--
Hiram Chirino
Engineering | Red Hat, Inc.
hchirino@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
Re: [VOTE] Apache Artemis 1.2.0
Posted by Andy Taylor <an...@gmail.com>.
I think that's doable. I'll see if I can come up with a PR over the
Christmas period and report back.
On Wed, 23 Dec 2015 23:24 John D. Ament <jo...@apache.org> wrote:
> +1 for a prompt on broker creation.
>
> It could even include a prompt, say "No libaio detected, to make your
> Artemis server faster please install libaio and {do necessary step to
> enable in broker}" but if it is installed, just prompt/given flag.
>
> John
>
> On Wed, Dec 23, 2015 at 5:07 PM Daniel Kulp <dk...@apache.org> wrote:
>
> >
> > > On Dec 23, 2015, at 4:55 PM, Andy Taylor <an...@gmail.com>
> wrote:
> > > I Guess it depends on what they mean by enabled. If the user has to
> > > explicitly install it then to me it's optional. Saying that if it's
> > > installed by default on the OS you could argue the opposite.
> >
> > The issue with the is that the user may not even know if they have it
> > installed or not. For example, on my two gentoo linux boxes, one has
> it
> > installed and one doesn’t. I have no idea why the one that has it
> > installed has it. With the package management and such, something I
> > installed there some time in the past must have caused it to install.
> > (likely mysql)
> >
> > > We could change the cli to prompt for a choice at create time.
> >
> > That would certainly work.
> >
> > Dan
> >
> >
> >
> > > On Wed, 23 Dec 2015 21:41 Daniel Kulp <dk...@apache.org> wrote:
> > >
> > >>
> > >>> On Dec 23, 2015, at 4:07 PM, John D. Ament <jo...@apache.org>
> > >> wrote:
> > >>>
> > >>> Are you referring to the bin or src distribution?
> > >>
> > >> Kind of both…
> > >>
> > >> By removing the binary from the src distribution, that covers that
> case.
> > >> The user would have to cd into the appropriate directory and
> explicitly
> > >> run the “make” or whatever to build the binary. It’s an explicit
> > choice
> > >> they make. Thus, I’m completely OK with that now.
> > >>
> > >>
> > >> The bin distribution is still an issue. If the default was to not
> use
> > >> the libaio at all unless the user either edited a config file to
> enable
> > it
> > >> or pass a command line flag or similar to take explicit action, I’d be
> > OK
> > >> there as well. The new wording on the legal pages is completely
> > >> confusing. The original suggested wording in:
> > >> https://issues.apache.org/jira/browse/LEGAL-54
> > >> makes so much more sense:
> > >>
> > >> "However, projects may use LGPL licensed works in optional features
> that
> > >> are not enabled by default.”
> > >>
> > >>
> > >> Dan
> > >>
> > >>
> > >>
> > >>>
> > >>> On Wed, Dec 23, 2015 at 4:05 PM Daniel Kulp <dk...@apache.org>
> wrote:
> > >>>
> > >>>>
> > >>>> Question: If I grab Artemis 1.1.0 tarbal/zip and start up the broker
> > >> “out
> > >>>> of the box”, does it use libaio or not? If I specifically have to
> > >>>> configure something (pass a flag, edit a config file, etc…) to
> enable
> > >> use
> > >>>> if the LGPL library, then fine. However, if it’s something that
> > >> occurs
> > >>>> completely automatically without the user even knowing that it’s
> > >> occurring,
> > >>>> then I have a major problem with it. It needs to be something that
> > the
> > >>>> user has to explicitly CHOOSE to use.
> > >>>>
> > >>>> Dan
> > >>>>
> > >>>>
> > >>>>
> > >>>>> On Dec 23, 2015, at 2:02 PM, Clebert Suconic <
> > >> clebert.suconic@gmail.com>
> > >>>> wrote:
> > >>>>>
> > >>>>> also, there has also been questions about it during the donation
> > >>>>> process.. licenses reviewed.. etc.. so I don't think we need to
> open
> > a
> > >>>>> new discussions over this. the binary inclusion on the source was
> > >>>>> something that was fixed now.
> > >>>>>
> > >>>>> The dependency on libaio on the C code is through through dynamic
> > >>>>> linked library, and is the same as any C code depending on libc or
> > >>>>> gcc.
> > >>>>>
> > >>>>> On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
> > >>>>> <cl...@gmail.com> wrote:
> > >>>>>> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament <
> > johndament@apache.org
> > >>>
> > >>>> wrote:
> > >>>>>>> Just wondering, does anyone plan to raise the LGPL question w/
> > legal
> > >>>>>>> discuss? If we're waiting for the new year to do the next
> release,
> > >>>> would
> > >>>>>>> be good to at least start the discussion.
> > >>>>>>
> > >>>>>>
> > >>>>>> We had such discussion long ago with legal. I couldn't find that
> > email
> > >>>>>> on my inbox but we specifically asked questions about it. We were
> ok
> > >>>>>> as I remember. Maybe someone else (Martyn?) will have it on their
> > >>>>>> inboxes. For that reason I don't want to go over the same issue we
> > had
> > >>>>>> asked before.
> > >>>>>>
> > >>>>>> The use of libaio is optional anyways and the system works as
> > >>>>>> expected. what also covers other questions we had here on this
> > thread.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>> Clebert Suconic
> > >>>>
> > >>>> --
> > >>>> Daniel Kulp
> > >>>> dkulp@apache.org - http://dankulp.com/blog
> > >>>> Talend Community Coder - http://coders.talend.com
> > >>>>
> > >>>>
> > >>
> > >> --
> > >> Daniel Kulp
> > >> dkulp@apache.org - http://dankulp.com/blog
> > >> Talend Community Coder - http://coders.talend.com
> > >>
> > >>
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
> >
>
Re: [VOTE] Apache Artemis 1.2.0
Posted by "John D. Ament" <jo...@apache.org>.
+1 for a prompt on broker creation.
It could even include a prompt, say "No libaio detected, to make your
Artemis server faster please install libaio and {do necessary step to
enable in broker}" but if it is installed, just prompt/given flag.
John
On Wed, Dec 23, 2015 at 5:07 PM Daniel Kulp <dk...@apache.org> wrote:
>
> > On Dec 23, 2015, at 4:55 PM, Andy Taylor <an...@gmail.com> wrote:
> > I Guess it depends on what they mean by enabled. If the user has to
> > explicitly install it then to me it's optional. Saying that if it's
> > installed by default on the OS you could argue the opposite.
>
> The issue with the is that the user may not even know if they have it
> installed or not. For example, on my two gentoo linux boxes, one has it
> installed and one doesn’t. I have no idea why the one that has it
> installed has it. With the package management and such, something I
> installed there some time in the past must have caused it to install.
> (likely mysql)
>
> > We could change the cli to prompt for a choice at create time.
>
> That would certainly work.
>
> Dan
>
>
>
> > On Wed, 23 Dec 2015 21:41 Daniel Kulp <dk...@apache.org> wrote:
> >
> >>
> >>> On Dec 23, 2015, at 4:07 PM, John D. Ament <jo...@apache.org>
> >> wrote:
> >>>
> >>> Are you referring to the bin or src distribution?
> >>
> >> Kind of both…
> >>
> >> By removing the binary from the src distribution, that covers that case.
> >> The user would have to cd into the appropriate directory and explicitly
> >> run the “make” or whatever to build the binary. It’s an explicit
> choice
> >> they make. Thus, I’m completely OK with that now.
> >>
> >>
> >> The bin distribution is still an issue. If the default was to not use
> >> the libaio at all unless the user either edited a config file to enable
> it
> >> or pass a command line flag or similar to take explicit action, I’d be
> OK
> >> there as well. The new wording on the legal pages is completely
> >> confusing. The original suggested wording in:
> >> https://issues.apache.org/jira/browse/LEGAL-54
> >> makes so much more sense:
> >>
> >> "However, projects may use LGPL licensed works in optional features that
> >> are not enabled by default.”
> >>
> >>
> >> Dan
> >>
> >>
> >>
> >>>
> >>> On Wed, Dec 23, 2015 at 4:05 PM Daniel Kulp <dk...@apache.org> wrote:
> >>>
> >>>>
> >>>> Question: If I grab Artemis 1.1.0 tarbal/zip and start up the broker
> >> “out
> >>>> of the box”, does it use libaio or not? If I specifically have to
> >>>> configure something (pass a flag, edit a config file, etc…) to enable
> >> use
> >>>> if the LGPL library, then fine. However, if it’s something that
> >> occurs
> >>>> completely automatically without the user even knowing that it’s
> >> occurring,
> >>>> then I have a major problem with it. It needs to be something that
> the
> >>>> user has to explicitly CHOOSE to use.
> >>>>
> >>>> Dan
> >>>>
> >>>>
> >>>>
> >>>>> On Dec 23, 2015, at 2:02 PM, Clebert Suconic <
> >> clebert.suconic@gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> also, there has also been questions about it during the donation
> >>>>> process.. licenses reviewed.. etc.. so I don't think we need to open
> a
> >>>>> new discussions over this. the binary inclusion on the source was
> >>>>> something that was fixed now.
> >>>>>
> >>>>> The dependency on libaio on the C code is through through dynamic
> >>>>> linked library, and is the same as any C code depending on libc or
> >>>>> gcc.
> >>>>>
> >>>>> On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
> >>>>> <cl...@gmail.com> wrote:
> >>>>>> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament <
> johndament@apache.org
> >>>
> >>>> wrote:
> >>>>>>> Just wondering, does anyone plan to raise the LGPL question w/
> legal
> >>>>>>> discuss? If we're waiting for the new year to do the next release,
> >>>> would
> >>>>>>> be good to at least start the discussion.
> >>>>>>
> >>>>>>
> >>>>>> We had such discussion long ago with legal. I couldn't find that
> email
> >>>>>> on my inbox but we specifically asked questions about it. We were ok
> >>>>>> as I remember. Maybe someone else (Martyn?) will have it on their
> >>>>>> inboxes. For that reason I don't want to go over the same issue we
> had
> >>>>>> asked before.
> >>>>>>
> >>>>>> The use of libaio is optional anyways and the system works as
> >>>>>> expected. what also covers other questions we had here on this
> thread.
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Clebert Suconic
> >>>>
> >>>> --
> >>>> Daniel Kulp
> >>>> dkulp@apache.org - http://dankulp.com/blog
> >>>> Talend Community Coder - http://coders.talend.com
> >>>>
> >>>>
> >>
> >> --
> >> Daniel Kulp
> >> dkulp@apache.org - http://dankulp.com/blog
> >> Talend Community Coder - http://coders.talend.com
> >>
> >>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
Re: [VOTE] Apache Artemis 1.2.0
Posted by Daniel Kulp <dk...@apache.org>.
> On Dec 23, 2015, at 4:55 PM, Andy Taylor <an...@gmail.com> wrote:
> I Guess it depends on what they mean by enabled. If the user has to
> explicitly install it then to me it's optional. Saying that if it's
> installed by default on the OS you could argue the opposite.
The issue with the is that the user may not even know if they have it installed or not. For example, on my two gentoo linux boxes, one has it installed and one doesn’t. I have no idea why the one that has it installed has it. With the package management and such, something I installed there some time in the past must have caused it to install. (likely mysql)
> We could change the cli to prompt for a choice at create time.
That would certainly work.
Dan
> On Wed, 23 Dec 2015 21:41 Daniel Kulp <dk...@apache.org> wrote:
>
>>
>>> On Dec 23, 2015, at 4:07 PM, John D. Ament <jo...@apache.org>
>> wrote:
>>>
>>> Are you referring to the bin or src distribution?
>>
>> Kind of both…
>>
>> By removing the binary from the src distribution, that covers that case.
>> The user would have to cd into the appropriate directory and explicitly
>> run the “make” or whatever to build the binary. It’s an explicit choice
>> they make. Thus, I’m completely OK with that now.
>>
>>
>> The bin distribution is still an issue. If the default was to not use
>> the libaio at all unless the user either edited a config file to enable it
>> or pass a command line flag or similar to take explicit action, I’d be OK
>> there as well. The new wording on the legal pages is completely
>> confusing. The original suggested wording in:
>> https://issues.apache.org/jira/browse/LEGAL-54
>> makes so much more sense:
>>
>> "However, projects may use LGPL licensed works in optional features that
>> are not enabled by default.”
>>
>>
>> Dan
>>
>>
>>
>>>
>>> On Wed, Dec 23, 2015 at 4:05 PM Daniel Kulp <dk...@apache.org> wrote:
>>>
>>>>
>>>> Question: If I grab Artemis 1.1.0 tarbal/zip and start up the broker
>> “out
>>>> of the box”, does it use libaio or not? If I specifically have to
>>>> configure something (pass a flag, edit a config file, etc…) to enable
>> use
>>>> if the LGPL library, then fine. However, if it’s something that
>> occurs
>>>> completely automatically without the user even knowing that it’s
>> occurring,
>>>> then I have a major problem with it. It needs to be something that the
>>>> user has to explicitly CHOOSE to use.
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>>> On Dec 23, 2015, at 2:02 PM, Clebert Suconic <
>> clebert.suconic@gmail.com>
>>>> wrote:
>>>>>
>>>>> also, there has also been questions about it during the donation
>>>>> process.. licenses reviewed.. etc.. so I don't think we need to open a
>>>>> new discussions over this. the binary inclusion on the source was
>>>>> something that was fixed now.
>>>>>
>>>>> The dependency on libaio on the C code is through through dynamic
>>>>> linked library, and is the same as any C code depending on libc or
>>>>> gcc.
>>>>>
>>>>> On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
>>>>> <cl...@gmail.com> wrote:
>>>>>> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament <johndament@apache.org
>>>
>>>> wrote:
>>>>>>> Just wondering, does anyone plan to raise the LGPL question w/ legal
>>>>>>> discuss? If we're waiting for the new year to do the next release,
>>>> would
>>>>>>> be good to at least start the discussion.
>>>>>>
>>>>>>
>>>>>> We had such discussion long ago with legal. I couldn't find that email
>>>>>> on my inbox but we specifically asked questions about it. We were ok
>>>>>> as I remember. Maybe someone else (Martyn?) will have it on their
>>>>>> inboxes. For that reason I don't want to go over the same issue we had
>>>>>> asked before.
>>>>>>
>>>>>> The use of libaio is optional anyways and the system works as
>>>>>> expected. what also covers other questions we had here on this thread.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Clebert Suconic
>>>>
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org - http://dankulp.com/blog
>>>> Talend Community Coder - http://coders.talend.com
>>>>
>>>>
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache Artemis 1.2.0
Posted by Andy Taylor <an...@gmail.com>.
I Guess it depends on what they mean by enabled. If the user has to
explicitly install it then to me it's optional. Saying that if it's
installed by default on the OS you could argue the opposite.
We could change the cli to prompt for a choice at create time.
On Wed, 23 Dec 2015 21:41 Daniel Kulp <dk...@apache.org> wrote:
>
> > On Dec 23, 2015, at 4:07 PM, John D. Ament <jo...@apache.org>
> wrote:
> >
> > Are you referring to the bin or src distribution?
>
> Kind of both…
>
> By removing the binary from the src distribution, that covers that case.
> The user would have to cd into the appropriate directory and explicitly
> run the “make” or whatever to build the binary. It’s an explicit choice
> they make. Thus, I’m completely OK with that now.
>
>
> The bin distribution is still an issue. If the default was to not use
> the libaio at all unless the user either edited a config file to enable it
> or pass a command line flag or similar to take explicit action, I’d be OK
> there as well. The new wording on the legal pages is completely
> confusing. The original suggested wording in:
> https://issues.apache.org/jira/browse/LEGAL-54
> makes so much more sense:
>
> "However, projects may use LGPL licensed works in optional features that
> are not enabled by default.”
>
>
> Dan
>
>
>
> >
> > On Wed, Dec 23, 2015 at 4:05 PM Daniel Kulp <dk...@apache.org> wrote:
> >
> >>
> >> Question: If I grab Artemis 1.1.0 tarbal/zip and start up the broker
> “out
> >> of the box”, does it use libaio or not? If I specifically have to
> >> configure something (pass a flag, edit a config file, etc…) to enable
> use
> >> if the LGPL library, then fine. However, if it’s something that
> occurs
> >> completely automatically without the user even knowing that it’s
> occurring,
> >> then I have a major problem with it. It needs to be something that the
> >> user has to explicitly CHOOSE to use.
> >>
> >> Dan
> >>
> >>
> >>
> >>> On Dec 23, 2015, at 2:02 PM, Clebert Suconic <
> clebert.suconic@gmail.com>
> >> wrote:
> >>>
> >>> also, there has also been questions about it during the donation
> >>> process.. licenses reviewed.. etc.. so I don't think we need to open a
> >>> new discussions over this. the binary inclusion on the source was
> >>> something that was fixed now.
> >>>
> >>> The dependency on libaio on the C code is through through dynamic
> >>> linked library, and is the same as any C code depending on libc or
> >>> gcc.
> >>>
> >>> On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
> >>> <cl...@gmail.com> wrote:
> >>>> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament <johndament@apache.org
> >
> >> wrote:
> >>>>> Just wondering, does anyone plan to raise the LGPL question w/ legal
> >>>>> discuss? If we're waiting for the new year to do the next release,
> >> would
> >>>>> be good to at least start the discussion.
> >>>>
> >>>>
> >>>> We had such discussion long ago with legal. I couldn't find that email
> >>>> on my inbox but we specifically asked questions about it. We were ok
> >>>> as I remember. Maybe someone else (Martyn?) will have it on their
> >>>> inboxes. For that reason I don't want to go over the same issue we had
> >>>> asked before.
> >>>>
> >>>> The use of libaio is optional anyways and the system works as
> >>>> expected. what also covers other questions we had here on this thread.
> >>>
> >>>
> >>>
> >>> --
> >>> Clebert Suconic
> >>
> >> --
> >> Daniel Kulp
> >> dkulp@apache.org - http://dankulp.com/blog
> >> Talend Community Coder - http://coders.talend.com
> >>
> >>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
Re: [VOTE] Apache Artemis 1.2.0
Posted by "John D. Ament" <jo...@apache.org>.
On Wed, Dec 23, 2015 at 6:24 PM Hiram Chirino <hi...@hiramchirino.com>
wrote:
> So I think the current policy is not that hard to understand.
>
> It basically says that we cannot redistribute category x licensed bits.
> Check.
>
There's a difference between depend on and distribute with.
I'm inclined to say that the libaio situation is similar to relying on
bash, GPL software. It's something the OS provides. No one's distributing
it, and the library leveraged by Artemis is an Apache V2 licensed piece of
software derived from the LGPL library.
But honestly, even PMC/member discussions are just speculative. The
definitive answer comes from legal.
I'm unable to find anything on the legal tracker for "libaio" or "hornetq"
so I'm not sure where those discussions occurred. I can search their
emails next.
John
>
> Using the LGPL licensed libaio does not require us to change our license.
> Check.
>
> So we are working in a scenario similar to what is described in the "DOES
> IT MATTER WHAT PLATFORM AN APACHE PRODUCT IS CREATED TO WORK WITH?" Section
> of
> http://www.apache.org/legal/resolved.html
>
> Libaio is a platform API that we use if it's available.
>
>
> On Wednesday, December 23, 2015, Daniel Kulp <dk...@apache.org> wrote:
>
> >
> > > On Dec 23, 2015, at 4:07 PM, John D. Ament <johndament@apache.org
> > <javascript:;>> wrote:
> > >
> > > Are you referring to the bin or src distribution?
> >
> > Kind of both…
> >
> > By removing the binary from the src distribution, that covers that case.
> > The user would have to cd into the appropriate directory and explicitly
> > run the “make” or whatever to build the binary. It’s an explicit choice
> > they make. Thus, I’m completely OK with that now.
> >
> >
> > The bin distribution is still an issue. If the default was to not use
> > the libaio at all unless the user either edited a config file to enable
> it
> > or pass a command line flag or similar to take explicit action, I’d be OK
> > there as well. The new wording on the legal pages is completely
> > confusing. The original suggested wording in:
> > https://issues.apache.org/jira/browse/LEGAL-54
> > makes so much more sense:
> >
> > "However, projects may use LGPL licensed works in optional features that
> > are not enabled by default.”
> >
> >
> > Dan
> >
> >
> >
> > >
> > > On Wed, Dec 23, 2015 at 4:05 PM Daniel Kulp <dkulp@apache.org
> > <javascript:;>> wrote:
> > >
> > >>
> > >> Question: If I grab Artemis 1.1.0 tarbal/zip and start up the broker
> > “out
> > >> of the box”, does it use libaio or not? If I specifically have to
> > >> configure something (pass a flag, edit a config file, etc…) to enable
> > use
> > >> if the LGPL library, then fine. However, if it’s something that
> > occurs
> > >> completely automatically without the user even knowing that it’s
> > occurring,
> > >> then I have a major problem with it. It needs to be something that
> the
> > >> user has to explicitly CHOOSE to use.
> > >>
> > >> Dan
> > >>
> > >>
> > >>
> > >>> On Dec 23, 2015, at 2:02 PM, Clebert Suconic <
> > clebert.suconic@gmail.com <javascript:;>>
> > >> wrote:
> > >>>
> > >>> also, there has also been questions about it during the donation
> > >>> process.. licenses reviewed.. etc.. so I don't think we need to open
> a
> > >>> new discussions over this. the binary inclusion on the source was
> > >>> something that was fixed now.
> > >>>
> > >>> The dependency on libaio on the C code is through through dynamic
> > >>> linked library, and is the same as any C code depending on libc or
> > >>> gcc.
> > >>>
> > >>> On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
> > >>> <clebert.suconic@gmail.com <javascript:;>> wrote:
> > >>>> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament <
> johndament@apache.org
> > <javascript:;>>
> > >> wrote:
> > >>>>> Just wondering, does anyone plan to raise the LGPL question w/
> legal
> > >>>>> discuss? If we're waiting for the new year to do the next release,
> > >> would
> > >>>>> be good to at least start the discussion.
> > >>>>
> > >>>>
> > >>>> We had such discussion long ago with legal. I couldn't find that
> email
> > >>>> on my inbox but we specifically asked questions about it. We were ok
> > >>>> as I remember. Maybe someone else (Martyn?) will have it on their
> > >>>> inboxes. For that reason I don't want to go over the same issue we
> had
> > >>>> asked before.
> > >>>>
> > >>>> The use of libaio is optional anyways and the system works as
> > >>>> expected. what also covers other questions we had here on this
> thread.
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Clebert Suconic
> > >>
> > >> --
> > >> Daniel Kulp
> > >> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
> > >> Talend Community Coder - http://coders.talend.com
> > >>
> > >>
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org <javascript:;> - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
> >
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> hchirino@redhat.com | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino
>
Re: [VOTE] Apache Artemis 1.2.0
Posted by Hiram Chirino <hi...@hiramchirino.com>.
So I think the current policy is not that hard to understand.
It basically says that we cannot redistribute category x licensed bits.
Check.
Using the LGPL licensed libaio does not require us to change our license.
Check.
So we are working in a scenario similar to what is described in the "DOES
IT MATTER WHAT PLATFORM AN APACHE PRODUCT IS CREATED TO WORK WITH?" Section
of
http://www.apache.org/legal/resolved.html
Libaio is a platform API that we use if it's available.
On Wednesday, December 23, 2015, Daniel Kulp <dk...@apache.org> wrote:
>
> > On Dec 23, 2015, at 4:07 PM, John D. Ament <johndament@apache.org
> <javascript:;>> wrote:
> >
> > Are you referring to the bin or src distribution?
>
> Kind of both…
>
> By removing the binary from the src distribution, that covers that case.
> The user would have to cd into the appropriate directory and explicitly
> run the “make” or whatever to build the binary. It’s an explicit choice
> they make. Thus, I’m completely OK with that now.
>
>
> The bin distribution is still an issue. If the default was to not use
> the libaio at all unless the user either edited a config file to enable it
> or pass a command line flag or similar to take explicit action, I’d be OK
> there as well. The new wording on the legal pages is completely
> confusing. The original suggested wording in:
> https://issues.apache.org/jira/browse/LEGAL-54
> makes so much more sense:
>
> "However, projects may use LGPL licensed works in optional features that
> are not enabled by default.”
>
>
> Dan
>
>
>
> >
> > On Wed, Dec 23, 2015 at 4:05 PM Daniel Kulp <dkulp@apache.org
> <javascript:;>> wrote:
> >
> >>
> >> Question: If I grab Artemis 1.1.0 tarbal/zip and start up the broker
> “out
> >> of the box”, does it use libaio or not? If I specifically have to
> >> configure something (pass a flag, edit a config file, etc…) to enable
> use
> >> if the LGPL library, then fine. However, if it’s something that
> occurs
> >> completely automatically without the user even knowing that it’s
> occurring,
> >> then I have a major problem with it. It needs to be something that the
> >> user has to explicitly CHOOSE to use.
> >>
> >> Dan
> >>
> >>
> >>
> >>> On Dec 23, 2015, at 2:02 PM, Clebert Suconic <
> clebert.suconic@gmail.com <javascript:;>>
> >> wrote:
> >>>
> >>> also, there has also been questions about it during the donation
> >>> process.. licenses reviewed.. etc.. so I don't think we need to open a
> >>> new discussions over this. the binary inclusion on the source was
> >>> something that was fixed now.
> >>>
> >>> The dependency on libaio on the C code is through through dynamic
> >>> linked library, and is the same as any C code depending on libc or
> >>> gcc.
> >>>
> >>> On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
> >>> <clebert.suconic@gmail.com <javascript:;>> wrote:
> >>>> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament <johndament@apache.org
> <javascript:;>>
> >> wrote:
> >>>>> Just wondering, does anyone plan to raise the LGPL question w/ legal
> >>>>> discuss? If we're waiting for the new year to do the next release,
> >> would
> >>>>> be good to at least start the discussion.
> >>>>
> >>>>
> >>>> We had such discussion long ago with legal. I couldn't find that email
> >>>> on my inbox but we specifically asked questions about it. We were ok
> >>>> as I remember. Maybe someone else (Martyn?) will have it on their
> >>>> inboxes. For that reason I don't want to go over the same issue we had
> >>>> asked before.
> >>>>
> >>>> The use of libaio is optional anyways and the system works as
> >>>> expected. what also covers other questions we had here on this thread.
> >>>
> >>>
> >>>
> >>> --
> >>> Clebert Suconic
> >>
> >> --
> >> Daniel Kulp
> >> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
> >> Talend Community Coder - http://coders.talend.com
> >>
> >>
>
> --
> Daniel Kulp
> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
--
Hiram Chirino
Engineering | Red Hat, Inc.
hchirino@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
Re: [VOTE] Apache Artemis 1.2.0
Posted by Daniel Kulp <dk...@apache.org>.
> On Dec 23, 2015, at 4:07 PM, John D. Ament <jo...@apache.org> wrote:
>
> Are you referring to the bin or src distribution?
Kind of both…
By removing the binary from the src distribution, that covers that case. The user would have to cd into the appropriate directory and explicitly run the “make” or whatever to build the binary. It’s an explicit choice they make. Thus, I’m completely OK with that now.
The bin distribution is still an issue. If the default was to not use the libaio at all unless the user either edited a config file to enable it or pass a command line flag or similar to take explicit action, I’d be OK there as well. The new wording on the legal pages is completely confusing. The original suggested wording in:
https://issues.apache.org/jira/browse/LEGAL-54
makes so much more sense:
"However, projects may use LGPL licensed works in optional features that are not enabled by default.”
Dan
>
> On Wed, Dec 23, 2015 at 4:05 PM Daniel Kulp <dk...@apache.org> wrote:
>
>>
>> Question: If I grab Artemis 1.1.0 tarbal/zip and start up the broker “out
>> of the box”, does it use libaio or not? If I specifically have to
>> configure something (pass a flag, edit a config file, etc…) to enable use
>> if the LGPL library, then fine. However, if it’s something that occurs
>> completely automatically without the user even knowing that it’s occurring,
>> then I have a major problem with it. It needs to be something that the
>> user has to explicitly CHOOSE to use.
>>
>> Dan
>>
>>
>>
>>> On Dec 23, 2015, at 2:02 PM, Clebert Suconic <cl...@gmail.com>
>> wrote:
>>>
>>> also, there has also been questions about it during the donation
>>> process.. licenses reviewed.. etc.. so I don't think we need to open a
>>> new discussions over this. the binary inclusion on the source was
>>> something that was fixed now.
>>>
>>> The dependency on libaio on the C code is through through dynamic
>>> linked library, and is the same as any C code depending on libc or
>>> gcc.
>>>
>>> On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
>>> <cl...@gmail.com> wrote:
>>>> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament <jo...@apache.org>
>> wrote:
>>>>> Just wondering, does anyone plan to raise the LGPL question w/ legal
>>>>> discuss? If we're waiting for the new year to do the next release,
>> would
>>>>> be good to at least start the discussion.
>>>>
>>>>
>>>> We had such discussion long ago with legal. I couldn't find that email
>>>> on my inbox but we specifically asked questions about it. We were ok
>>>> as I remember. Maybe someone else (Martyn?) will have it on their
>>>> inboxes. For that reason I don't want to go over the same issue we had
>>>> asked before.
>>>>
>>>> The use of libaio is optional anyways and the system works as
>>>> expected. what also covers other questions we had here on this thread.
>>>
>>>
>>>
>>> --
>>> Clebert Suconic
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache Artemis 1.2.0
Posted by Clebert Suconic <cl...@gmail.com>.
Libaio is a kernel feature. Part of the Linux kernel.
It's optional and the cli default to it if available in the OS. As Andy said.
If what you are saying was true thought Apache HTTP would for instance have serious problems with libc and other libraries it's using for example.
Libaio is part of the architecture / OS we are running on.
But regardless it's use is optional. I don't see a reason for such big deal at this time.
> On Dec 23, 2015, at 4:15 PM, Andy Taylor <an...@gmail.com> wrote:
>
> It's a configuration option in the broker.xml. however by default the cli
> will default to use it. Saying that it will only use it if it's libation
> has been installed, if it hasn't then NIO us used.
>
>> On Wed, 23 Dec 2015 21:07 John D. Ament <jo...@apache.org> wrote:
>>
>> Are you referring to the bin or src distribution?
>>
>>> On Wed, Dec 23, 2015 at 4:05 PM Daniel Kulp <dk...@apache.org> wrote:
>>>
>>>
>>> Question: If I grab Artemis 1.1.0 tarbal/zip and start up the broker “out
>>> of the box”, does it use libaio or not? If I specifically have to
>>> configure something (pass a flag, edit a config file, etc…) to enable use
>>> if the LGPL library, then fine. However, if it’s something that occurs
>>> completely automatically without the user even knowing that it’s
>> occurring,
>>> then I have a major problem with it. It needs to be something that the
>>> user has to explicitly CHOOSE to use.
>>>
>>> Dan
>>>
>>>
>>>
>>>> On Dec 23, 2015, at 2:02 PM, Clebert Suconic <
>> clebert.suconic@gmail.com>
>>> wrote:
>>>>
>>>> also, there has also been questions about it during the donation
>>>> process.. licenses reviewed.. etc.. so I don't think we need to open a
>>>> new discussions over this. the binary inclusion on the source was
>>>> something that was fixed now.
>>>>
>>>> The dependency on libaio on the C code is through through dynamic
>>>> linked library, and is the same as any C code depending on libc or
>>>> gcc.
>>>>
>>>> On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
>>>> <cl...@gmail.com> wrote:
>>>>> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament <johndament@apache.org
>>>
>>> wrote:
>>>>>> Just wondering, does anyone plan to raise the LGPL question w/ legal
>>>>>> discuss? If we're waiting for the new year to do the next release,
>>> would
>>>>>> be good to at least start the discussion.
>>>>>
>>>>>
>>>>> We had such discussion long ago with legal. I couldn't find that email
>>>>> on my inbox but we specifically asked questions about it. We were ok
>>>>> as I remember. Maybe someone else (Martyn?) will have it on their
>>>>> inboxes. For that reason I don't want to go over the same issue we had
>>>>> asked before.
>>>>>
>>>>> The use of libaio is optional anyways and the system works as
>>>>> expected. what also covers other questions we had here on this thread.
>>>>
>>>>
>>>>
>>>> --
>>>> Clebert Suconic
>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>
Re: [VOTE] Apache Artemis 1.2.0
Posted by Andy Taylor <an...@gmail.com>.
It's a configuration option in the broker.xml. however by default the cli
will default to use it. Saying that it will only use it if it's libation
has been installed, if it hasn't then NIO us used.
On Wed, 23 Dec 2015 21:07 John D. Ament <jo...@apache.org> wrote:
> Are you referring to the bin or src distribution?
>
> On Wed, Dec 23, 2015 at 4:05 PM Daniel Kulp <dk...@apache.org> wrote:
>
> >
> > Question: If I grab Artemis 1.1.0 tarbal/zip and start up the broker “out
> > of the box”, does it use libaio or not? If I specifically have to
> > configure something (pass a flag, edit a config file, etc…) to enable use
> > if the LGPL library, then fine. However, if it’s something that occurs
> > completely automatically without the user even knowing that it’s
> occurring,
> > then I have a major problem with it. It needs to be something that the
> > user has to explicitly CHOOSE to use.
> >
> > Dan
> >
> >
> >
> > > On Dec 23, 2015, at 2:02 PM, Clebert Suconic <
> clebert.suconic@gmail.com>
> > wrote:
> > >
> > > also, there has also been questions about it during the donation
> > > process.. licenses reviewed.. etc.. so I don't think we need to open a
> > > new discussions over this. the binary inclusion on the source was
> > > something that was fixed now.
> > >
> > > The dependency on libaio on the C code is through through dynamic
> > > linked library, and is the same as any C code depending on libc or
> > > gcc.
> > >
> > > On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
> > > <cl...@gmail.com> wrote:
> > >> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament <johndament@apache.org
> >
> > wrote:
> > >>> Just wondering, does anyone plan to raise the LGPL question w/ legal
> > >>> discuss? If we're waiting for the new year to do the next release,
> > would
> > >>> be good to at least start the discussion.
> > >>
> > >>
> > >> We had such discussion long ago with legal. I couldn't find that email
> > >> on my inbox but we specifically asked questions about it. We were ok
> > >> as I remember. Maybe someone else (Martyn?) will have it on their
> > >> inboxes. For that reason I don't want to go over the same issue we had
> > >> asked before.
> > >>
> > >> The use of libaio is optional anyways and the system works as
> > >> expected. what also covers other questions we had here on this thread.
> > >
> > >
> > >
> > > --
> > > Clebert Suconic
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
> >
>
Re: [VOTE] Apache Artemis 1.2.0
Posted by "John D. Ament" <jo...@apache.org>.
Are you referring to the bin or src distribution?
On Wed, Dec 23, 2015 at 4:05 PM Daniel Kulp <dk...@apache.org> wrote:
>
> Question: If I grab Artemis 1.1.0 tarbal/zip and start up the broker “out
> of the box”, does it use libaio or not? If I specifically have to
> configure something (pass a flag, edit a config file, etc…) to enable use
> if the LGPL library, then fine. However, if it’s something that occurs
> completely automatically without the user even knowing that it’s occurring,
> then I have a major problem with it. It needs to be something that the
> user has to explicitly CHOOSE to use.
>
> Dan
>
>
>
> > On Dec 23, 2015, at 2:02 PM, Clebert Suconic <cl...@gmail.com>
> wrote:
> >
> > also, there has also been questions about it during the donation
> > process.. licenses reviewed.. etc.. so I don't think we need to open a
> > new discussions over this. the binary inclusion on the source was
> > something that was fixed now.
> >
> > The dependency on libaio on the C code is through through dynamic
> > linked library, and is the same as any C code depending on libc or
> > gcc.
> >
> > On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
> > <cl...@gmail.com> wrote:
> >> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament <jo...@apache.org>
> wrote:
> >>> Just wondering, does anyone plan to raise the LGPL question w/ legal
> >>> discuss? If we're waiting for the new year to do the next release,
> would
> >>> be good to at least start the discussion.
> >>
> >>
> >> We had such discussion long ago with legal. I couldn't find that email
> >> on my inbox but we specifically asked questions about it. We were ok
> >> as I remember. Maybe someone else (Martyn?) will have it on their
> >> inboxes. For that reason I don't want to go over the same issue we had
> >> asked before.
> >>
> >> The use of libaio is optional anyways and the system works as
> >> expected. what also covers other questions we had here on this thread.
> >
> >
> >
> > --
> > Clebert Suconic
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
Re: [VOTE] Apache Artemis 1.2.0
Posted by Daniel Kulp <dk...@apache.org>.
Question: If I grab Artemis 1.1.0 tarbal/zip and start up the broker “out of the box”, does it use libaio or not? If I specifically have to configure something (pass a flag, edit a config file, etc…) to enable use if the LGPL library, then fine. However, if it’s something that occurs completely automatically without the user even knowing that it’s occurring, then I have a major problem with it. It needs to be something that the user has to explicitly CHOOSE to use.
Dan
> On Dec 23, 2015, at 2:02 PM, Clebert Suconic <cl...@gmail.com> wrote:
>
> also, there has also been questions about it during the donation
> process.. licenses reviewed.. etc.. so I don't think we need to open a
> new discussions over this. the binary inclusion on the source was
> something that was fixed now.
>
> The dependency on libaio on the C code is through through dynamic
> linked library, and is the same as any C code depending on libc or
> gcc.
>
> On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
> <cl...@gmail.com> wrote:
>> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament <jo...@apache.org> wrote:
>>> Just wondering, does anyone plan to raise the LGPL question w/ legal
>>> discuss? If we're waiting for the new year to do the next release, would
>>> be good to at least start the discussion.
>>
>>
>> We had such discussion long ago with legal. I couldn't find that email
>> on my inbox but we specifically asked questions about it. We were ok
>> as I remember. Maybe someone else (Martyn?) will have it on their
>> inboxes. For that reason I don't want to go over the same issue we had
>> asked before.
>>
>> The use of libaio is optional anyways and the system works as
>> expected. what also covers other questions we had here on this thread.
>
>
>
> --
> Clebert Suconic
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache Artemis 1.2.0
Posted by Clebert Suconic <cl...@gmail.com>.
also, there has also been questions about it during the donation
process.. licenses reviewed.. etc.. so I don't think we need to open a
new discussions over this. the binary inclusion on the source was
something that was fixed now.
The dependency on libaio on the C code is through through dynamic
linked library, and is the same as any C code depending on libc or
gcc.
On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
<cl...@gmail.com> wrote:
> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament <jo...@apache.org> wrote:
>> Just wondering, does anyone plan to raise the LGPL question w/ legal
>> discuss? If we're waiting for the new year to do the next release, would
>> be good to at least start the discussion.
>
>
> We had such discussion long ago with legal. I couldn't find that email
> on my inbox but we specifically asked questions about it. We were ok
> as I remember. Maybe someone else (Martyn?) will have it on their
> inboxes. For that reason I don't want to go over the same issue we had
> asked before.
>
> The use of libaio is optional anyways and the system works as
> expected. what also covers other questions we had here on this thread.
--
Clebert Suconic
Re: [VOTE] Apache Artemis 1.2.0
Posted by Clebert Suconic <cl...@gmail.com>.
On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament <jo...@apache.org> wrote:
> Just wondering, does anyone plan to raise the LGPL question w/ legal
> discuss? If we're waiting for the new year to do the next release, would
> be good to at least start the discussion.
We had such discussion long ago with legal. I couldn't find that email
on my inbox but we specifically asked questions about it. We were ok
as I remember. Maybe someone else (Martyn?) will have it on their
inboxes. For that reason I don't want to go over the same issue we had
asked before.
The use of libaio is optional anyways and the system works as
expected. what also covers other questions we had here on this thread.
Re: [VOTE] Apache Artemis 1.2.0
Posted by "John D. Ament" <jo...@apache.org>.
Just wondering, does anyone plan to raise the LGPL question w/ legal
discuss? If we're waiting for the new year to do the next release, would
be good to at least start the discussion.
John
On Wed, Dec 23, 2015 at 11:04 AM Andy Taylor <an...@gmail.com> wrote:
> Claus,
>
> fyi, Ive sent a PR with some of your suggestions, see
> https://github.com/apache/activemq-artemis/pull/287.
>
> I'll take a look at the stuff ive missed in the new year.
>
> Merry Christmas.
>
> Andy
>
> On 21/12/15 07:45, Claus Ibsen wrote:
> > On Mon, Dec 21, 2015 at 1:03 AM, Clebert Suconic
> > <cl...@gmail.com> wrote:
> >>> Also the output of the help command in the html looks ugly. Its not
> >>> spaced correctly.
> >>
> >> I'm not sure where you mean that?
> >>
> >
> > Open the readme.html in your browser. And then compare that to the
> > --help output from the CLI. At least in my browser the formatting in
> > the readme.html is not presented nicely.
> >
> > eg remember this is about first impression, new users is likely to
> > open the readme as the 1st thing.
> >
> >
> >
> >>
> >>>
> >>> And its a bit unclear that after creating a broker you must cd into
> >>> that directory to start it. eg some people may think you can start the
> >>> broker from the unzip like you can do in Apache ActiveMQ. I would like
> >>> to see the readme more clear on this. Maybe a better step by step
> >>> showing the commands and output etc so its really clear.
> >>
> >> +1
> >>
> >>>
> >>> Also why not use a .md file instead of .html ?
> >>
> >> I'm confused what's best here. .html are easy to read (thinking of
> >> beginners just downloading the distro). pehaps we could switch to .md
> >> and have a converter tool? (although I wouldn't know which one to use
> >> from maven).
> >>
> >>>
> >>> In JMX the broker is listed as brokerName="0.0.0.0" but I was not
> >>> given any opportunity to name the broker when I created it from the
> >>> command line.
> >>
> >> the cli will only ask for the host if needed (that is if you're using
> >> clustered). otherwise you can use options (use ./artemis help create
> >> for that).
> >>
> >>>
> >>> And I cannot see the broker name in the log when the broker start up.
> >>> That name should IMHO be allowed to enter when creating, and maybe
> >>> default to the directory name or something? And show the name in the
> >>> log.
> >>
> >>
> >> That's used for the JMX only.
> >>
> >
> > Its still a part of naming the broker. IMHO you should not hide that
> > fact. People should be able to see from the logs what the name would
> > be in JMX so they are sure they find the correct broker.
> >
> > Now its also seldom to use 2+ message brokers in the same JVM. Not
> > sure that is really best practice.
> >
> > Since the broker name is "dynamic" then it makes tooling harder to
> > predict the mbean name tree. As 99,9% uses 1 broker in the JVM why not
> > have it default as before. And then if you really want 2+ then you
> > need to enable configure the managementBrokerName to make them unique
> > in that tree.
> >
> >
> >
> >>>
> >>> Also I would like to be abel to easily enable jolokia out of the box.
> >>> Apache ActiveMQ has that, but Artemis does not.
> >>
> >> It doest.. it's part of the web interface.
> >
> > If Jolokia is enabled then please log the jolokia url in the logs when
> > you start up. See how we do that in ActiveMQ.
> >
> > I can find some details in the user guide
> > http://activemq.apache.org/artemis/docs/1.1.0/management.html
> >
> > And btw there is typo in the docs -
> >
> > example to query thebrokers version
> >
> > -->
> >
> > there is no space between thebrokers
> >
> >
> >
> >>
> >>>
> >>> The web console is likely a bit disappointment, its just the
> >>> documentation. People in 2015 would expect a management console. So
> >>> maybe point that out in the docs that there is none (yet).
> >>
> >> +1
> >>
> >>>
> >>> When you create a queue its logged at INFO level and the message is
> >>> not with a capital letter, eg trying -> Trying
> >>>
> >>
> >> +1 I was so used to this message that I never though about that.
> >>
> >>> And when the broker shutdown, I would like to see an INFO logging that
> >>> says the uptime of the broker. See how we do that in ActiveMQ.
> >>
> >>
> >> +1 Nice feature.
> >>
> >>
> >>> Also IMHO you should log at INFO level when the broker is being
> >>> shutdown, so the user can see from exactly in the log when the
> >>> shutdown starts, in case there is problems during so.
> >>>
> >>> eg as shown above where I started ActiveMQ in the foreground, and then
> >>> hit CTRL+C (eg ^C).
> >>>
> >>
> >>
> >> I will open the JIRAs for these on monday. (Or maybe commit those if
> >> it's an easy fix).
> >>
> >>
> >> I don't see a reason to withdraw the release based on your feedback.
> >> Great stuff but I don't see a need to hold it (hence your +1 already)
> >
> > Yes its a +1 - great to see a new release out.
> >
>
>
Re: [VOTE] Apache Artemis 1.2.0
Posted by Andy Taylor <an...@gmail.com>.
Claus,
fyi, Ive sent a PR with some of your suggestions, see
https://github.com/apache/activemq-artemis/pull/287.
I'll take a look at the stuff ive missed in the new year.
Merry Christmas.
Andy
On 21/12/15 07:45, Claus Ibsen wrote:
> On Mon, Dec 21, 2015 at 1:03 AM, Clebert Suconic
> <cl...@gmail.com> wrote:
>>> Also the output of the help command in the html looks ugly. Its not
>>> spaced correctly.
>>
>> I'm not sure where you mean that?
>>
>
> Open the readme.html in your browser. And then compare that to the
> --help output from the CLI. At least in my browser the formatting in
> the readme.html is not presented nicely.
>
> eg remember this is about first impression, new users is likely to
> open the readme as the 1st thing.
>
>
>
>>
>>>
>>> And its a bit unclear that after creating a broker you must cd into
>>> that directory to start it. eg some people may think you can start the
>>> broker from the unzip like you can do in Apache ActiveMQ. I would like
>>> to see the readme more clear on this. Maybe a better step by step
>>> showing the commands and output etc so its really clear.
>>
>> +1
>>
>>>
>>> Also why not use a .md file instead of .html ?
>>
>> I'm confused what's best here. .html are easy to read (thinking of
>> beginners just downloading the distro). pehaps we could switch to .md
>> and have a converter tool? (although I wouldn't know which one to use
>> from maven).
>>
>>>
>>> In JMX the broker is listed as brokerName="0.0.0.0" but I was not
>>> given any opportunity to name the broker when I created it from the
>>> command line.
>>
>> the cli will only ask for the host if needed (that is if you're using
>> clustered). otherwise you can use options (use ./artemis help create
>> for that).
>>
>>>
>>> And I cannot see the broker name in the log when the broker start up.
>>> That name should IMHO be allowed to enter when creating, and maybe
>>> default to the directory name or something? And show the name in the
>>> log.
>>
>>
>> That's used for the JMX only.
>>
>
> Its still a part of naming the broker. IMHO you should not hide that
> fact. People should be able to see from the logs what the name would
> be in JMX so they are sure they find the correct broker.
>
> Now its also seldom to use 2+ message brokers in the same JVM. Not
> sure that is really best practice.
>
> Since the broker name is "dynamic" then it makes tooling harder to
> predict the mbean name tree. As 99,9% uses 1 broker in the JVM why not
> have it default as before. And then if you really want 2+ then you
> need to enable configure the managementBrokerName to make them unique
> in that tree.
>
>
>
>>>
>>> Also I would like to be abel to easily enable jolokia out of the box.
>>> Apache ActiveMQ has that, but Artemis does not.
>>
>> It doest.. it's part of the web interface.
>
> If Jolokia is enabled then please log the jolokia url in the logs when
> you start up. See how we do that in ActiveMQ.
>
> I can find some details in the user guide
> http://activemq.apache.org/artemis/docs/1.1.0/management.html
>
> And btw there is typo in the docs -
>
> example to query thebrokers version
>
> -->
>
> there is no space between thebrokers
>
>
>
>>
>>>
>>> The web console is likely a bit disappointment, its just the
>>> documentation. People in 2015 would expect a management console. So
>>> maybe point that out in the docs that there is none (yet).
>>
>> +1
>>
>>>
>>> When you create a queue its logged at INFO level and the message is
>>> not with a capital letter, eg trying -> Trying
>>>
>>
>> +1 I was so used to this message that I never though about that.
>>
>>> And when the broker shutdown, I would like to see an INFO logging that
>>> says the uptime of the broker. See how we do that in ActiveMQ.
>>
>>
>> +1 Nice feature.
>>
>>
>>> Also IMHO you should log at INFO level when the broker is being
>>> shutdown, so the user can see from exactly in the log when the
>>> shutdown starts, in case there is problems during so.
>>>
>>> eg as shown above where I started ActiveMQ in the foreground, and then
>>> hit CTRL+C (eg ^C).
>>>
>>
>>
>> I will open the JIRAs for these on monday. (Or maybe commit those if
>> it's an easy fix).
>>
>>
>> I don't see a reason to withdraw the release based on your feedback.
>> Great stuff but I don't see a need to hold it (hence your +1 already)
>
> Yes its a +1 - great to see a new release out.
>
Re: [VOTE] Apache Artemis 1.2.0
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Dec 21, 2015 at 1:03 AM, Clebert Suconic
<cl...@gmail.com> wrote:
>> Also the output of the help command in the html looks ugly. Its not
>> spaced correctly.
>
> I'm not sure where you mean that?
>
Open the readme.html in your browser. And then compare that to the
--help output from the CLI. At least in my browser the formatting in
the readme.html is not presented nicely.
eg remember this is about first impression, new users is likely to
open the readme as the 1st thing.
>
>>
>> And its a bit unclear that after creating a broker you must cd into
>> that directory to start it. eg some people may think you can start the
>> broker from the unzip like you can do in Apache ActiveMQ. I would like
>> to see the readme more clear on this. Maybe a better step by step
>> showing the commands and output etc so its really clear.
>
> +1
>
>>
>> Also why not use a .md file instead of .html ?
>
> I'm confused what's best here. .html are easy to read (thinking of
> beginners just downloading the distro). pehaps we could switch to .md
> and have a converter tool? (although I wouldn't know which one to use
> from maven).
>
>>
>> In JMX the broker is listed as brokerName="0.0.0.0" but I was not
>> given any opportunity to name the broker when I created it from the
>> command line.
>
> the cli will only ask for the host if needed (that is if you're using
> clustered). otherwise you can use options (use ./artemis help create
> for that).
>
>>
>> And I cannot see the broker name in the log when the broker start up.
>> That name should IMHO be allowed to enter when creating, and maybe
>> default to the directory name or something? And show the name in the
>> log.
>
>
> That's used for the JMX only.
>
Its still a part of naming the broker. IMHO you should not hide that
fact. People should be able to see from the logs what the name would
be in JMX so they are sure they find the correct broker.
Now its also seldom to use 2+ message brokers in the same JVM. Not
sure that is really best practice.
Since the broker name is "dynamic" then it makes tooling harder to
predict the mbean name tree. As 99,9% uses 1 broker in the JVM why not
have it default as before. And then if you really want 2+ then you
need to enable configure the managementBrokerName to make them unique
in that tree.
>>
>> Also I would like to be abel to easily enable jolokia out of the box.
>> Apache ActiveMQ has that, but Artemis does not.
>
> It doest.. it's part of the web interface.
If Jolokia is enabled then please log the jolokia url in the logs when
you start up. See how we do that in ActiveMQ.
I can find some details in the user guide
http://activemq.apache.org/artemis/docs/1.1.0/management.html
And btw there is typo in the docs -
example to query thebrokers version
-->
there is no space between thebrokers
>
>>
>> The web console is likely a bit disappointment, its just the
>> documentation. People in 2015 would expect a management console. So
>> maybe point that out in the docs that there is none (yet).
>
> +1
>
>>
>> When you create a queue its logged at INFO level and the message is
>> not with a capital letter, eg trying -> Trying
>>
>
> +1 I was so used to this message that I never though about that.
>
>> And when the broker shutdown, I would like to see an INFO logging that
>> says the uptime of the broker. See how we do that in ActiveMQ.
>
>
> +1 Nice feature.
>
>
>> Also IMHO you should log at INFO level when the broker is being
>> shutdown, so the user can see from exactly in the log when the
>> shutdown starts, in case there is problems during so.
>>
>> eg as shown above where I started ActiveMQ in the foreground, and then
>> hit CTRL+C (eg ^C).
>>
>
>
> I will open the JIRAs for these on monday. (Or maybe commit those if
> it's an easy fix).
>
>
> I don't see a reason to withdraw the release based on your feedback.
> Great stuff but I don't see a need to hold it (hence your +1 already)
Yes its a +1 - great to see a new release out.
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: [VOTE] Apache Artemis 1.2.0
Posted by Clebert Suconic <cl...@gmail.com>.
> Also the output of the help command in the html looks ugly. Its not
> spaced correctly.
I'm not sure where you mean that?
>
> And its a bit unclear that after creating a broker you must cd into
> that directory to start it. eg some people may think you can start the
> broker from the unzip like you can do in Apache ActiveMQ. I would like
> to see the readme more clear on this. Maybe a better step by step
> showing the commands and output etc so its really clear.
+1
>
> Also why not use a .md file instead of .html ?
I'm confused what's best here. .html are easy to read (thinking of
beginners just downloading the distro). pehaps we could switch to .md
and have a converter tool? (although I wouldn't know which one to use
from maven).
>
> In JMX the broker is listed as brokerName="0.0.0.0" but I was not
> given any opportunity to name the broker when I created it from the
> command line.
the cli will only ask for the host if needed (that is if you're using
clustered). otherwise you can use options (use ./artemis help create
for that).
>
> And I cannot see the broker name in the log when the broker start up.
> That name should IMHO be allowed to enter when creating, and maybe
> default to the directory name or something? And show the name in the
> log.
That's used for the JMX only.
>
> Also I would like to be abel to easily enable jolokia out of the box.
> Apache ActiveMQ has that, but Artemis does not.
It doest.. it's part of the web interface.
>
> The web console is likely a bit disappointment, its just the
> documentation. People in 2015 would expect a management console. So
> maybe point that out in the docs that there is none (yet).
+1
>
> When you create a queue its logged at INFO level and the message is
> not with a capital letter, eg trying -> Trying
>
+1 I was so used to this message that I never though about that.
> And when the broker shutdown, I would like to see an INFO logging that
> says the uptime of the broker. See how we do that in ActiveMQ.
+1 Nice feature.
> Also IMHO you should log at INFO level when the broker is being
> shutdown, so the user can see from exactly in the log when the
> shutdown starts, in case there is problems during so.
>
> eg as shown above where I started ActiveMQ in the foreground, and then
> hit CTRL+C (eg ^C).
>
I will open the JIRAs for these on monday. (Or maybe commit those if
it's an easy fix).
I don't see a reason to withdraw the release based on your feedback.
Great stuff but I don't see a need to hold it (hence your +1 already)
Re: [VOTE] Apache Artemis 1.2.0
Posted by Christopher Shannon <ch...@gmail.com>.
+1 (non-binding)
Built from source and ran the quick tests
Checked headers
Deployed and ran the broker from the binary on CentOS
Ran several different examples
On Mon, Dec 21, 2015 at 4:55 AM, Martyn Taylor <mt...@redhat.com> wrote:
> This is really great feedback Claus, it's exactly the type of thing we
> need. Thanks for taking the time to write this up.
>
> We'll get all your comments captured in JIRA and aim to address them in
> the next release.
>
>
> On 20/12/15 06:52, Claus Ibsen wrote:
>
>> Hi
>>
>> +1 (binding)
>>
>>
>> I gave the binary a quick spin, and created a broker
>>
>> The readme.html file does not include 1.2.0 changes. But I really
>> think the readme.html should not include that details, but refer to
>> the website for a changelog / migration guide etc. So the readme can
>> be short and simple.
>>
>> Also the output of the help command in the html looks ugly. Its not
>> spaced correctly.
>>
>> And its a bit unclear that after creating a broker you must cd into
>> that directory to start it. eg some people may think you can start the
>> broker from the unzip like you can do in Apache ActiveMQ. I would like
>> to see the readme more clear on this. Maybe a better step by step
>> showing the commands and output etc so its really clear.
>>
>> Also why not use a .md file instead of .html ?
>>
>> In JMX the broker is listed as brokerName="0.0.0.0" but I was not
>> given any opportunity to name the broker when I created it from the
>> command line.
>>
>> And I cannot see the broker name in the log when the broker start up.
>> That name should IMHO be allowed to enter when creating, and maybe
>> default to the directory name or something? And show the name in the
>> log.
>>
>> Also I would like to be abel to easily enable jolokia out of the box.
>> Apache ActiveMQ has that, but Artemis does not.
>>
>> The web console is likely a bit disappointment, its just the
>> documentation. People in 2015 would expect a management console. So
>> maybe point that out in the docs that there is none (yet).
>>
>> When you create a queue its logged at INFO level and the message is
>> not with a capital letter, eg trying -> Trying
>>
>> [org.apache.activemq.artemis.core.server] AMQ221003: trying to deploy
>> queue jms.queue.foo
>>
>> And is that a debug message instead of INFO ?
>>
>>
>> And when the broker shutdown, I would like to see an INFO logging that
>> says the uptime of the broker. See how we do that in ActiveMQ.
>>
>> ^C INFO | Apache ActiveMQ 5.13.0 (localhost,
>> ID:davsclaus.air-51151-1450593630078-0:1) is shutting down
>> ...
>> INFO | Apache ActiveMQ 5.13.0 (localhost,
>> ID:davsclaus.air-51151-1450593630078-0:1) uptime 13.012 seconds
>> INFO | Apache ActiveMQ 5.13.0 (localhost,
>> ID:davsclaus.air-51151-1450593630078-0:1) is shutdown
>>
>> Also IMHO you should log at INFO level when the broker is being
>> shutdown, so the user can see from exactly in the log when the
>> shutdown starts, in case there is problems during so.
>>
>> eg as shown above where I started ActiveMQ in the foreground, and then
>> hit CTRL+C (eg ^C).
>>
>>
>>
>>
>> But great to see a new release coming out at steady pace - keep up that.
>>
>> Really like the protocol detection on the single port. I would love to
>> see in JMX some MBeans that can list those protocols and their ports
>> in a tree, so tooling is able to discover that.
>>
>>
>>
>> On Fri, Dec 18, 2015 at 6:36 PM, Martyn Taylor <mt...@redhat.com>
>> wrote:
>>
>>> Hello all.
>>>
>>> I'd like to propose an Apache Artemis 1.2.0 release.
>>>
>>> Since 1.1.0 we've had some significant improvements to performance,
>>> particularly around the persistence layer. In addition new features have
>>> been added such as LDAP and OSGi support. There has also been more
>>> improvements to the OpenWire protocol.
>>>
>>> The release notes can be found here:
>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12333274
>>>
>>> The binary distributions can be found here:
>>>
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
>>>
>>> The source archives can be found here:
>>>
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
>>>
>>> The Maven repository is here:
>>>
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/
>>>
>>> The source tag:
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.2.0
>>>
>>> The project website for that version has been staged to:
>>> http://people.apache.org/~martyntaylor/
>>>
>>> The vote will remain open for 72 hours.
>>>
>>> [ ] +1 approve the release as Apache Artemis 1.2.0
>>> [ ] +0 no opinion
>>> [ ] -1 disapprove (and reason why)
>>>
>>> Here's my (non-binding) +1
>>>
>>> Regards
>>>
>>> Martyn
>>>
>>
>>
>>
>
Re: [VOTE] Apache Artemis 1.2.0
Posted by Martyn Taylor <mt...@redhat.com>.
This is really great feedback Claus, it's exactly the type of thing we
need. Thanks for taking the time to write this up.
We'll get all your comments captured in JIRA and aim to address them in
the next release.
On 20/12/15 06:52, Claus Ibsen wrote:
> Hi
>
> +1 (binding)
>
>
> I gave the binary a quick spin, and created a broker
>
> The readme.html file does not include 1.2.0 changes. But I really
> think the readme.html should not include that details, but refer to
> the website for a changelog / migration guide etc. So the readme can
> be short and simple.
>
> Also the output of the help command in the html looks ugly. Its not
> spaced correctly.
>
> And its a bit unclear that after creating a broker you must cd into
> that directory to start it. eg some people may think you can start the
> broker from the unzip like you can do in Apache ActiveMQ. I would like
> to see the readme more clear on this. Maybe a better step by step
> showing the commands and output etc so its really clear.
>
> Also why not use a .md file instead of .html ?
>
> In JMX the broker is listed as brokerName="0.0.0.0" but I was not
> given any opportunity to name the broker when I created it from the
> command line.
>
> And I cannot see the broker name in the log when the broker start up.
> That name should IMHO be allowed to enter when creating, and maybe
> default to the directory name or something? And show the name in the
> log.
>
> Also I would like to be abel to easily enable jolokia out of the box.
> Apache ActiveMQ has that, but Artemis does not.
>
> The web console is likely a bit disappointment, its just the
> documentation. People in 2015 would expect a management console. So
> maybe point that out in the docs that there is none (yet).
>
> When you create a queue its logged at INFO level and the message is
> not with a capital letter, eg trying -> Trying
>
> [org.apache.activemq.artemis.core.server] AMQ221003: trying to deploy
> queue jms.queue.foo
>
> And is that a debug message instead of INFO ?
>
>
> And when the broker shutdown, I would like to see an INFO logging that
> says the uptime of the broker. See how we do that in ActiveMQ.
>
> ^C INFO | Apache ActiveMQ 5.13.0 (localhost,
> ID:davsclaus.air-51151-1450593630078-0:1) is shutting down
> ...
> INFO | Apache ActiveMQ 5.13.0 (localhost,
> ID:davsclaus.air-51151-1450593630078-0:1) uptime 13.012 seconds
> INFO | Apache ActiveMQ 5.13.0 (localhost,
> ID:davsclaus.air-51151-1450593630078-0:1) is shutdown
>
> Also IMHO you should log at INFO level when the broker is being
> shutdown, so the user can see from exactly in the log when the
> shutdown starts, in case there is problems during so.
>
> eg as shown above where I started ActiveMQ in the foreground, and then
> hit CTRL+C (eg ^C).
>
>
>
>
> But great to see a new release coming out at steady pace - keep up that.
>
> Really like the protocol detection on the single port. I would love to
> see in JMX some MBeans that can list those protocols and their ports
> in a tree, so tooling is able to discover that.
>
>
>
> On Fri, Dec 18, 2015 at 6:36 PM, Martyn Taylor <mt...@redhat.com> wrote:
>> Hello all.
>>
>> I'd like to propose an Apache Artemis 1.2.0 release.
>>
>> Since 1.1.0 we've had some significant improvements to performance,
>> particularly around the persistence layer. In addition new features have
>> been added such as LDAP and OSGi support. There has also been more
>> improvements to the OpenWire protocol.
>>
>> The release notes can be found here:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12333274
>>
>> The binary distributions can be found here:
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
>>
>> The source archives can be found here:
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
>>
>> The Maven repository is here:
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/
>>
>> The source tag:
>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.2.0
>>
>> The project website for that version has been staged to:
>> http://people.apache.org/~martyntaylor/
>>
>> The vote will remain open for 72 hours.
>>
>> [ ] +1 approve the release as Apache Artemis 1.2.0
>> [ ] +0 no opinion
>> [ ] -1 disapprove (and reason why)
>>
>> Here's my (non-binding) +1
>>
>> Regards
>>
>> Martyn
>
>
Re: [VOTE] Apache Artemis 1.2.0
Posted by Christian Schneider <ch...@die-schneider.net>.
+1 (non binding)
Christian
2015-12-20 7:52 GMT+01:00 Claus Ibsen <cl...@gmail.com>:
> Hi
>
> +1 (binding)
>
>
> I gave the binary a quick spin, and created a broker
>
> The readme.html file does not include 1.2.0 changes. But I really
> think the readme.html should not include that details, but refer to
> the website for a changelog / migration guide etc. So the readme can
> be short and simple.
>
> Also the output of the help command in the html looks ugly. Its not
> spaced correctly.
>
> And its a bit unclear that after creating a broker you must cd into
> that directory to start it. eg some people may think you can start the
> broker from the unzip like you can do in Apache ActiveMQ. I would like
> to see the readme more clear on this. Maybe a better step by step
> showing the commands and output etc so its really clear.
>
> Also why not use a .md file instead of .html ?
>
> In JMX the broker is listed as brokerName="0.0.0.0" but I was not
> given any opportunity to name the broker when I created it from the
> command line.
>
> And I cannot see the broker name in the log when the broker start up.
> That name should IMHO be allowed to enter when creating, and maybe
> default to the directory name or something? And show the name in the
> log.
>
> Also I would like to be abel to easily enable jolokia out of the box.
> Apache ActiveMQ has that, but Artemis does not.
>
> The web console is likely a bit disappointment, its just the
> documentation. People in 2015 would expect a management console. So
> maybe point that out in the docs that there is none (yet).
>
> When you create a queue its logged at INFO level and the message is
> not with a capital letter, eg trying -> Trying
>
> [org.apache.activemq.artemis.core.server] AMQ221003: trying to deploy
> queue jms.queue.foo
>
> And is that a debug message instead of INFO ?
>
>
> And when the broker shutdown, I would like to see an INFO logging that
> says the uptime of the broker. See how we do that in ActiveMQ.
>
> ^C INFO | Apache ActiveMQ 5.13.0 (localhost,
> ID:davsclaus.air-51151-1450593630078-0:1) is shutting down
> ...
> INFO | Apache ActiveMQ 5.13.0 (localhost,
> ID:davsclaus.air-51151-1450593630078-0:1) uptime 13.012 seconds
> INFO | Apache ActiveMQ 5.13.0 (localhost,
> ID:davsclaus.air-51151-1450593630078-0:1) is shutdown
>
> Also IMHO you should log at INFO level when the broker is being
> shutdown, so the user can see from exactly in the log when the
> shutdown starts, in case there is problems during so.
>
> eg as shown above where I started ActiveMQ in the foreground, and then
> hit CTRL+C (eg ^C).
>
>
>
>
> But great to see a new release coming out at steady pace - keep up that.
>
> Really like the protocol detection on the single port. I would love to
> see in JMX some MBeans that can list those protocols and their ports
> in a tree, so tooling is able to discover that.
>
>
>
> On Fri, Dec 18, 2015 at 6:36 PM, Martyn Taylor <mt...@redhat.com> wrote:
> > Hello all.
> >
> > I'd like to propose an Apache Artemis 1.2.0 release.
> >
> > Since 1.1.0 we've had some significant improvements to performance,
> > particularly around the persistence layer. In addition new features have
> > been added such as LDAP and OSGi support. There has also been more
> > improvements to the OpenWire protocol.
> >
> > The release notes can be found here:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12333274
> >
> > The binary distributions can be found here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
> >
> > The source archives can be found here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
> >
> > The Maven repository is here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/
> >
> > The source tag:
> >
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.2.0
> >
> > The project website for that version has been staged to:
> > http://people.apache.org/~martyntaylor/
> >
> > The vote will remain open for 72 hours.
> >
> > [ ] +1 approve the release as Apache Artemis 1.2.0
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Here's my (non-binding) +1
> >
> > Regards
> >
> > Martyn
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
Re: [VOTE] Apache Artemis 1.2.0
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
+1 (binding)
I gave the binary a quick spin, and created a broker
The readme.html file does not include 1.2.0 changes. But I really
think the readme.html should not include that details, but refer to
the website for a changelog / migration guide etc. So the readme can
be short and simple.
Also the output of the help command in the html looks ugly. Its not
spaced correctly.
And its a bit unclear that after creating a broker you must cd into
that directory to start it. eg some people may think you can start the
broker from the unzip like you can do in Apache ActiveMQ. I would like
to see the readme more clear on this. Maybe a better step by step
showing the commands and output etc so its really clear.
Also why not use a .md file instead of .html ?
In JMX the broker is listed as brokerName="0.0.0.0" but I was not
given any opportunity to name the broker when I created it from the
command line.
And I cannot see the broker name in the log when the broker start up.
That name should IMHO be allowed to enter when creating, and maybe
default to the directory name or something? And show the name in the
log.
Also I would like to be abel to easily enable jolokia out of the box.
Apache ActiveMQ has that, but Artemis does not.
The web console is likely a bit disappointment, its just the
documentation. People in 2015 would expect a management console. So
maybe point that out in the docs that there is none (yet).
When you create a queue its logged at INFO level and the message is
not with a capital letter, eg trying -> Trying
[org.apache.activemq.artemis.core.server] AMQ221003: trying to deploy
queue jms.queue.foo
And is that a debug message instead of INFO ?
And when the broker shutdown, I would like to see an INFO logging that
says the uptime of the broker. See how we do that in ActiveMQ.
^C INFO | Apache ActiveMQ 5.13.0 (localhost,
ID:davsclaus.air-51151-1450593630078-0:1) is shutting down
...
INFO | Apache ActiveMQ 5.13.0 (localhost,
ID:davsclaus.air-51151-1450593630078-0:1) uptime 13.012 seconds
INFO | Apache ActiveMQ 5.13.0 (localhost,
ID:davsclaus.air-51151-1450593630078-0:1) is shutdown
Also IMHO you should log at INFO level when the broker is being
shutdown, so the user can see from exactly in the log when the
shutdown starts, in case there is problems during so.
eg as shown above where I started ActiveMQ in the foreground, and then
hit CTRL+C (eg ^C).
But great to see a new release coming out at steady pace - keep up that.
Really like the protocol detection on the single port. I would love to
see in JMX some MBeans that can list those protocols and their ports
in a tree, so tooling is able to discover that.
On Fri, Dec 18, 2015 at 6:36 PM, Martyn Taylor <mt...@redhat.com> wrote:
> Hello all.
>
> I'd like to propose an Apache Artemis 1.2.0 release.
>
> Since 1.1.0 we've had some significant improvements to performance,
> particularly around the persistence layer. In addition new features have
> been added such as LDAP and OSGi support. There has also been more
> improvements to the OpenWire protocol.
>
> The release notes can be found here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12333274
>
> The binary distributions can be found here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
>
> The source archives can be found here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/
>
> The source tag:
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.2.0
>
> The project website for that version has been staged to:
> http://people.apache.org/~martyntaylor/
>
> The vote will remain open for 72 hours.
>
> [ ] +1 approve the release as Apache Artemis 1.2.0
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here's my (non-binding) +1
>
> Regards
>
> Martyn
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: [VOTE] Apache Artemis 1.2.0
Posted by Hiram Chirino <hi...@hiramchirino.com>.
+1 (binding) All looks good to me.
On Fri, Dec 18, 2015 at 12:36 PM, Martyn Taylor <mt...@redhat.com> wrote:
> Hello all.
>
> I'd like to propose an Apache Artemis 1.2.0 release.
>
> Since 1.1.0 we've had some significant improvements to performance,
> particularly around the persistence layer. In addition new features have
> been added such as LDAP and OSGi support. There has also been more
> improvements to the OpenWire protocol.
>
> The release notes can be found here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12333274
>
> The binary distributions can be found here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
>
> The source archives can be found here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/
>
> The source tag:
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.2.0
>
> The project website for that version has been staged to:
> http://people.apache.org/~martyntaylor/
>
> The vote will remain open for 72 hours.
>
> [ ] +1 approve the release as Apache Artemis 1.2.0
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here's my (non-binding) +1
>
> Regards
>
> Martyn
--
Hiram Chirino
Engineering | Red Hat, Inc.
hchirino@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
Re: [VOTE] Apache Artemis 1.2.0
Posted by Timothy Bish <ta...@gmail.com>.
+1 (binding)
* Checked signatures and checksums
* Ran broker from binary and test with some external client code.
* Built from source and ran some tests.
* Checked for valid LICENSE and NOTICE files.
For the next release I'd encourage you to move ahead open issues that
are still targeting the release but aren't actually going to make it in,
several of the issues on the release notes page do not appear to be
items that will be resolved in this release:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12333274
Would make it easier to review what is supposed to be fixed in the
release being voted on.
On 12/18/2015 12:36 PM, Martyn Taylor wrote:
> Hello all.
>
> I'd like to propose an Apache Artemis 1.2.0 release.
>
> Since 1.1.0 we've had some significant improvements to performance,
> particularly around the persistence layer. In addition new features
> have been added such as LDAP and OSGi support. There has also been
> more improvements to the OpenWire protocol.
>
> The release notes can be found here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12333274
>
>
> The binary distributions can be found here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
>
>
> The source archives can be found here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
>
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/
>
>
> The source tag:
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.2.0
>
>
> The project website for that version has been staged to:
> http://people.apache.org/~martyntaylor/
>
> The vote will remain open for 72 hours.
>
> [ ] +1 approve the release as Apache Artemis 1.2.0
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here's my (non-binding) +1
>
> Regards
>
> Martyn
>
--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/
Re: [VOTE] Apache Artemis 1.2.0
Posted by Andy Taylor <an...@gmail.com>.
+1 (non binding)
created and ran a server and a few examples. built from source ok. all
on windows 10
On 18/12/15 17:36, Martyn Taylor wrote:
> Hello all.
>
> I'd like to propose an Apache Artemis 1.2.0 release.
>
> Since 1.1.0 we've had some significant improvements to performance,
> particularly around the persistence layer. In addition new features
> have been added such as LDAP and OSGi support. There has also been more
> improvements to the OpenWire protocol.
>
> The release notes can be found here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12333274
>
>
> The binary distributions can be found here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
>
>
> The source archives can be found here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/org/apache/activemq/apache-artemis/1.2.0/
>
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1076/
>
> The source tag:
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.2.0
>
>
> The project website for that version has been staged to:
> http://people.apache.org/~martyntaylor/
>
> The vote will remain open for 72 hours.
>
> [ ] +1 approve the release as Apache Artemis 1.2.0
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here's my (non-binding) +1
>
> Regards
>
> Martyn