Art,
You can track the progress here:
https://issues.apache.org/jira/browse/AMQ-7087
I just pushed a commit to my github and posted some comments about it. The
main problem with JDK 11 is they made it modular and took out java EE
classes so we now have to include new jars. OSGi support is also
@Gary Tully - thank you for the clarification.
@Christopher Shannon - for my personal
learning -- do you have a link to a good read on what it takes to support
JDK 11? Or can you give a brief list of issues? I'm curious of the
technical parts involved.
Art
On Thu, Nov 29, 2018 at 8:14 AM
JDK 11 support sounds great :)
On Thu, Nov 29, 2018 at 11:34 AM Jean-Baptiste Onofré wrote:
>
> It sounds good for JDK 11. It's something I planned to start for a while
> (now that JDK 11 support is complete in Karaf). Don't hesitate to ping
> me if I can help.
>
> Thanks
> Regards
> JB
>
> On
It sounds good for JDK 11. It's something I planned to start for a while
(now that JDK 11 support is complete in Karaf). Don't hesitate to ping
me if I can help.
Thanks
Regards
JB
On 29/11/2018 16:02, Christopher Shannon wrote:
> I'm actually working on getting JDK 11 support right now. The
I'm actually working on getting JDK 11 support right now. The idea is
ActiveMQ will still have a compile/runtime target of JDK 8 but will run
without issue on JDK 11 and be able to be built with JDK 11 etc. We need
to have that done before going to 5.16.0 as long as a bunch of dependency
iMHO since you are now a commuter you have the power to call it 5,16.0. And
even make a release when you are ready.
On Thu, Nov 29, 2018 at 7:53 AM Jamie G. wrote:
> Hi Gary,
>
> Just want to clarify, you're asking to wait for 5.16.0 to be released,
> than bring in the refactoring effort?
>
>
Hi Gary,
Just want to clarify, you're asking to wait for 5.16.0 to be released,
than bring in the refactoring effort?
If you feel 5.16.0 is imminent than I'm happy to hold off. I'd prefer
to get this in sooner rather than later so as to reduce the amount of
rebasing/cherry picking i need to do
Hey Arthur,
I am not asserting that they need to be small.
I am pointing out that they currently are small changes; there has
been no significant refactor to date; it is all very conservative.
Release 5.16.0 as a line in the sand, then move code around to make it
better etc.. go for it.
I know
Hi Clebert,
I've run the full set of test suites with these changes to passing tests.
I'm happy to expand upon unit testing of course.
On Tue, Nov 27, 2018 at 3:53 PM Clebert Suconic
wrote:
>
> I'm getting too old now to realize that the most expensive thing in
> *any* messaging system is
gtully wrote
> Jamie,
> you are missing my point. it is a tradeoff plain and simple. easier to
> maintain for who? It has been carefully maintained for more than 7
> years.
I am a bit confused and surprised. Its been maintained for 7 years by a
small select few of what has become stovepipe app
Hey Gary - I agree that these changes belong on a minor version increase.
What I don't understand is the assertion that the changes between 5.15.x
and 5.16.0 need to be small. Given that the minor version bump can mean
significant changes, as long as they are backward compatible, I see no
reason
Jamie,
you are missing my point. it is a tradeoff plain and simple. easier to
maintain for who? It has been carefully maintained for more than 7
years.
Do refactoring at the beginning of a release cycle, not at the end.
diffs between 5.15.x and 5.16 will be meaningless otherwise.
push out 5.16.0,
I'm getting too old now to realize that the most expensive thing in
*any* messaging system is testing.
I know you could say this to any system, but in messaging in general
this is prominent.
So, I'm not too concerned with the change itself as I am with the
amount of testing done. I have seen many
Hi Gary,
To address your concerns:
1. The code is being cleaned up, not completely rewritten. This is
making it easier to maintain over the monolithic classes. It's also
why it was brought to the community… to review it and be sure the
changes are just cleaning it up. There was no intent to
Hi Jamie G,
There are a few trade offs to consider:
1) those familiar with the code will have to reacquaint themselves
with anything that is refactored
2) backporting fixes will be more difficult when the code structure changes
Of the two, I think #2 is more critical.
On #1:
context builds up
I didn't say I definitely wouldn't support it but I just want to make sure
we are careful and the benefits of the refactor (in this case improved
maintainability) are really going to be worth the risk specifically because
of the component being touched. Too often things get committed and then
Improving the existing code is a great goal.
While cleaning up code is nice KahaDB has gotten pretty stable over the
> years and doing a bunch of refactoring just opens it up to new bugs that
> have to be fixed. Fixing bugs is not a problem however I tend to be more
> sensitive to store related
FWIW, the current community goal is for ActiveMQ Artemis to become ActiveMQ
6.x when acceptable feature parity is reached (which is actively being
worked on).
Justin
On Mon, Nov 26, 2018 at 11:01 AM Jamie G. wrote:
> The idea here is to ensure that it’s development and maintenance
> moving
The idea here is to ensure that it’s development and maintenance
moving forward is easier as we work to make it better in the future.
KahaDB currently has massive classes (KahaDBStore, MessageDatabase)
and code base and is extremely hard to follow. My desire to do this
was to make this so we
I'm not really sure this is worthwhile or something we want to do...I would
have to think about it more before I gave it a +1.
While cleaning up code is nice KahaDB has gotten pretty stable over the
years and doing a bunch of refactoring just opens it up to new bugs that
have to be fixed. Fixing
OK, got it. It's more a syntax/codebase organization refactoring.
If there's no impact on the behavior and features, +1 from my side.
Regards
JB
On 25/11/2018 21:21, Jamie G. wrote:
> Initially its to make KahaDB classes easier to read & maintain.
> Eventually it will help in
Initially its to make KahaDB classes easier to read & maintain.
Eventually it will help in features/performance; smaller classes are
easier to grok, easier to see improvements.
Instead of trying to refactor all of it in one go, I'm taking the
approach of one area at a time.
One pass for breaking
Hi Jamie,
That's interesting.
What's the rationale behind the refactoring ? New features or perf
improvements ?
Regards
JB
On 25/11/2018 20:16, Jamie G. wrote:
> Hi All,
>
> I've taken some time to prototype a refactored KahaDBStore class:
>
Hi All,
I've taken some time to prototype a refactored KahaDBStore class:
https://github.com/jgoodyear/activemq/tree/KahaDBRefactor
As KahaDBStore exists in Master, it contains 7 internal classes, over
some 1677 lines of code.
In my refactor branch I've separated out those classes into their
24 matches
Mail list logo
