Now when you join to the project I have a little bit more motivation to do next steps 😉

Maybe you want do join with help? We can describe tasks to do and do it together.

yes, Im just retaking a project that will use this, also Im just going back to code a bit .. so I can take some stuff after I finish to do some work on the project, I can also help testing the new version structure and if you change the reflection part.

I've been took this idea from e.g. https://github.com/go-gitea/gitea/labels?q=kind or https://github.com/spring-projects/spring-framework/labels?q=type

Maybe type: * is better, but I strongly recommend to use prefix to describe type of the label.

ok no problem for me

Sure! There should be a 3.39.0 version 😉

Before I respond to this, does it supersede the proposed roadmap you created previously?

I think it enriches the roadmap. This list should work with the roadmap.

I don't have a ton of time right now but I'll address a couple of the items while I do:

1. Migrate from Maven to Gradle
   For me, Gradle feels more natural. Many of the largest open-source communities use Gradle (such as Spring and OpenTelemetry).

There would have to be some pretty compelling benefits to using Gradle for me to consider moving away from Maven. I could swap "Maven" for "Gradle" in your sentence above (and swap in a few large OSS projects using Maven) and that would be my justification for sticking with Maven.

2. Modularization ...

Sure.

3. Introduce integration testing using Testcontainers

I don't feel strongly about this (and it doesn't sound like something I would want to work on), but if it's something you wanted to spearhead, go for it.

4. Introduce Netty

That's fine. It would be useful on the AGI, ARI (future), and AudioSocket (future) sides. Not so much on the AMI side but no reason we couldn't use it there too.

5. Introduce new serializers and deserializers

I need some more time to review this code to understand what you are proposing. This replaces the AMI event/action/response parsing I assume?

A few minor things I want to do for v4 are:

1. Remove our home-grown logging abstraction in favor of slf4j's
2. Potentially auto-generate AMI actions/events from Asterisk XML documentation.
3. There was a 3rd but it disappeared from my brain before I could write it down. Will update later. Change master to main. I think I remember seeing someone else (you?) mention that elsewhere.

There would have to be some pretty compelling benefits to using Gradle for me to consider moving away from Maven.

I mentioned that the Gradle feels more natural to me. Personally, I don't like XML. Gradle is much cleaner than the XML in Maven, which creates a lot of noise. I don't have any deal breakers, though I prefer Gradle.

Remove our home-grown logging abstraction in favor of slf4j's

It sounds extremely appealing. Totally agree.

Potentially auto-generate AMI actions/events from Asterisk XML documentation.

I'm not familiar with this concept. Could you share some additional info or links?

Change master to main. I think I remember seeing someone else (you?) mention that elsewhere.

Yes, definitely!

What do you think we should start with? Maybe renaming master to main would be a goot first step. But what should we do next?

Potentially auto-generate AMI actions/events from Asterisk XML documentation.

I'm not familiar with this concept. Could you share some additional info or links?

There is XML documentation embedded within the source code of Asterisk that is extracted and merged into an XML file (typically /var/lib/asterisk/documentation/core-en_US.xml) used by the asterisk process for the help system.

I'm suggesting leveraging that file to generate our action/event "models" (e.g. org.asteriskjava.manager.action.GetVarAction). There is very little, if any, type information in that file so my thought is that we would build something that turned core-en_US.xml into another format (yaml maybe) that we could then hand edit to add type information and then use that file to generate the Java code.

What do you think we should start with? Maybe renaming master to main would be a goot first step. But what should we do next?

Since we're in agreement I'll go ahead and change the branch name. Should we branch off a 3.x branch and start working on v4 in main? I think splitting into multiple modules would be a good first step after that.

Actually we should probably wait to branch 3.x until we’re ready to release 4.0. I know you have a 4.x branch but would it make sense to start over since we’ll stick with Maven?