aesteve
Vert.x version parity
I started using Nubes which is great and really makes things easier. However I noticed the Vert.x version supported is 3.3.3, which works. I would like to user a newer version of Vert.x; 3.4.2. I prefer the latest GA version of Vert.x, however it seems some changes to Nubes are required to make it work, otherwise there are errors at runtime. Any plans to update it?
Hello.
Sorry I have to work on this. Unfortunately no ETA at the moment. I can't work from home since I have no internet connection.
I hope I can work on this asap.
Sorry for the inconvenience.
@aesteve Okay, no worries. Looking forward to the update and thanks for the library!
I'll need some help unfortunately.
I checked version 3.5, there's soooo much work to do to adapt I'll never have time to do it by myself.
I think I relied on too many internal features of Vert.x.
@aesteve do you know what needs to change and do you detail outline of list of things to do?
it would be nice to accept more collaborators to your repo @aesteve so the project can continue to evolve, there seem to be interest for it.
I'd be really happy to do so !
What do I need to do precisely ? Changing some settings ?
Thanks.
@aesteve if you can create a Wiki page detailing out the changes required to support the latest version of 3.5 and what you would like to change in way of feature that you think should not have been used as they were internal features and what to avoid. Once you have documented this, I can then look at how to help you in making this happen. Also, you might need to add me to the contributor's list, but we should wait for that once I read thru the scope of changes?
@aesteve I think you can start by adding in the README that you don't actively develop the project anymore but you accept contributions via Pull Requests and you can deploy it on Maven Central to make new versions. So you need to define how people contribute to it and your responsibility is to merge PRs and eventually release it. How does that sound ?
@vietj I already indicated on top of the README that I can't manage the project anylonger. So I guess this point is covered already.
I can add that any contribution by PR is warmly welcomed, obviously. np with that.
I never deployed Nubes to maven central, so no change on that point.
I can still deploy on jcenter if needed, but I'd be way more confident if people forked the project and deployed it on their own. I guess it's a better choice in the long run not to depend on me.
@pratikpparikh I'm afraid creating such a wiki page is a big amount of work I'm really concerned of. Last time I took the time to check, the AuthHandler stuff had to be reworked completely, but even more concerning, with vertx-web having made huge improvements in the way it handles consumes, accepts for instance, the internal of Nubes had to be rewritten completely. The best you can do is check out the project, change vert.x dependency and launch the tests. You'll get a very good glimpse at what is not working.
@aesteve Thanks for some insight. I will give it a spin this weekend.
@aesteve Can you provide some documentation for MultipleFutures was/is doing? You don't have any documentation and I don't want to assume what needs/is to happen with it.
my question is more in line with #56 which is what @vietj wonder, but it is hard to make that call before understanding the full scope of your goals with MultipleFutures and what uses case it solves in details. #56 has a very short description. Does explain clearly at least to me.
iirc, most of the code from MultipleFutures is now covered by CompositeFuture, but there's one huge exception to the rule (last time I checked, at least) :
This method has a very different goal : it launches computations.