You mentioned on the 5.15.11 vote thread that a 5.16.0 vote would
happen in late November, but it was suggested to skip that particular
week and so folks had returned from holidays around US Thanksgiving.
Its been a bit longer now, but is the intent still to release 5.16.0
very soon? I ask as the t
It seems like an announcement never happened. The draft board report
mentions 5.15.12, is that likely to be soon? If it is then its
probably not worth announcing 5.15.11 now given it has been 6 weeks
and folks might be better going to the followup instead.
Robbie
On Wed, 18 Dec 2019 at 15:05, Rob
JMS 2.0 is definitely not going into 5.16.0 but maybe some future release
if someone wanted to do the work. However, I seriously doubt 5.x will
ever support it as it would be a lot of work to update the broker including
the datastores to support it and Artemis already has support.
On Mon, Jan 6,
Hi Robbie,
Due to the Jekyll issue, I forgot to send the announcement e-mail, sorry
about that.
And yeah, I already a series of cherry picks from master (coming 5.16.0)
to 5.15.x branch (coming 5.15.12).
I plan to have 5.15.12 to vote by the end of this month.
Agree to "use" 5.15.12 for announc
Hi Robbie,
yeah, 5.16.0 is still my top priority and it's almost ready. JDK 9+ is
OK (including on Karaf). JMS 2.0 is "optional" for 5.16.0 (but I think
it's worth to try to have it). So, it's more an indication in terms of
"best effort", not a strong commitment.
In term of timeline, 5.16.0 could
Hi,
agree, but I started the work about JMS 2.0 first simple support (both
broker and connection factory sides), and it seems to not be so
large/impacting.
That's why I proposed to support it if the effort is not so huge.
Regards
JB
On 06/01/2020 12:30, Christopher Shannon wrote:
> JMS 2.0 is de
JB,
The biggest problem is going to be the datastore for JMS 2.0 to support
shared subscriptions. You would need to track shared subscriptions in the
store so that will be a good amount of work to make sure it doesn't break
anything. This will also require a new openwire version for storing as
w
Even if it were almost complete, which it doesnt sound like it is,
such a significant change would still seem better positioned for a
5.17.0 at this point than dropped into an almost-ready 5.16.0 at the
last moment.
Either way I would suggest updating the draft report to be clearer as
it doesnt cu
I agree with Robbie, it's a -1 from me to try and include JMS 2.0 at this
point in 5.16.0 as it's way too late to try and add such a big change. It
needs to be 5.17.0 or higher.
On Mon, Jan 6, 2020 at 7:23 AM Robbie Gemmell
wrote:
> Even if it were almost complete, which it doesnt sound like i
Yes, so JDK 9+ on 5.16.0 and JMS 2.0 after 5.16.0. Fair enough, I'm
moving forward like this.
Thanks for your feedback guys.
Regards
JB
On 06/01/2020 13:36, Christopher Shannon wrote:
> I agree with Robbie, it's a -1 from me to try and include JMS 2.0 at this
> point in 5.16.0 as it's way too la
Hi JB,
Thank you for your contributions! All the information you provided is very
helpful.
Bruce
On Mon, Jan 6, 2020 at 12:14 AM Jean-Baptiste Onofré
wrote:
> Hi Bruce,
>
> Happy new year to you as well !
>
> I added some content about ActiveMQ (releases, stats, overall activity).
> Please let
Hi Robbie,
Thank you for your contributions! You are correct that the board does not
want a complete copy/paste from the Reporter tool, so I usually just grab a
few relevant stats from it and add them to the report.
Bruce
On Mon, Jan 6, 2020 at 3:53 AM Robbie Gemmell
wrote:
> You mentioned on
Hi JB,
As Robbie mentioned, the board has complained in the past when the ActiveMQ
report included a large amount of copy/paste from the Reporter tool. This
is why I am send emails to this list begging for contributions from the
folks who are currently toiling on the project.
Bruce
On Mon, Jan 6
Hi All,
I'm happy to see that the report triggered a discussion regarding the JMS
2.0 impl.
Thank you to everyone for the hard work on this major new feature and the
JDK 9+ support!
Bruce
On Mon, Jan 6, 2020 at 7:24 AM Jean-Baptiste Onofré wrote:
> Yes, so JDK 9+ on 5.16.0 and JMS 2.0 after 5
I ran your code and reproduced the issue you're seeing. Everything appears
to be working as expected. Let me explain...
> Both addresses get created correctly and the queue on the first address
gets created correctly but for some reason when I try to create the second
queue on the second address i
Perhaps we need to fix something on path for the tests. Those are probably
test issues.
On Sat, Jan 4, 2020 at 12:28 PM Krzysztof wrote:
> Just a heads up. I've tried to run the whole thing on Linux and it seems
> that everything works as it should. All the tests that are failing on
> Windows b
You're probably right. I am using Artemis on Windows on a regular basis and
everything works fine. It would be nice, if I could debug the tests on
windows as well, as my Linux VM is terribly slow.
On Mon, Jan 6, 2020 at 7:02 PM Clebert Suconic
wrote:
> Perhaps we need to fix something on path fo
For what it's worth a user reported an issue with a recent snapshot running
on Windows 10 [1]. This could be the root cause of the failures.
Justin
[1]
https://issues.apache.org/jira/browse/ARTEMIS-2583?focusedCommentId=17008030&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabp
Hi Justin,
Yes, it all makes sense now. I missed that part in the documentation. Thanks
for the quick response!
Brian R
> On Jan 6, 2020, at 11:43, Justin Bertram wrote:
>
> I ran your code and reproduced the issue you're seeing. Everything appears
> to be working as expected. Let me explai
19 matches
Mail list logo