To clarify, the subject says "move to" which sounds at first like "remove
and replace" - but that's not the intent, right? Just talking about adding
the JakartaEE API and keeping JMS 2.0, correct?
If it's just adding a new API, I have no strong feelings either way.
Art
On Tue, Sep 22, 2020 at
Hello,
Currently Artemis is exposing a JMS 2.0 API but Java EE has moved toward
JakartaEE.
For JakartaEE 9 there is only a namespace switch( with more coming on with
JakartaEE 10).
Shouldn't we propose new artefacts that expose Jakarta Messaging API too ?
Do yo have any idea on how to create and
Note I'm not saying you need to wait for all the build services to
complete before e.g merging a PR. If any one is finished, by all means
merge away.
On Tue, 22 Sep 2020 at 17:48, Robbie Gemmell wrote:
>
> I'm not objecting per se, but I dont see particular benefits to doing
> so. I said when
I'm not objecting per se, but I dont see particular benefits to doing
so. I said when introducing the GitHub Actions build that I actually
do see benefits to still running both, that remains true.
- Additional test runs are useful for spotting sporadic failure issues
creep in, and in seeing them
Quite a while back we started using Travis CI to run the PR builds for
Artemis. Recently support was added for GitHub Actions which run the same
builds as Travis CI. At this point, both Travis and GitHub are running the
same builds for Artemis PRs.
Does anybody object to removing Travis builds?
