Personally, I’m in a situation where I started via the Java quickstart, the quickstart said “Use this library” - and I never really looked back or considered configuring Spring directly.
I think part of it as well is not knowing that a better approach exists. I just looked at the spring quickstart and it’s changed a lot since I last looked at it, no mention of the library at all - so writing on the wall here is that y’all would prefer to turn this library off and just configure spring directly, hence your question
From an org perspective, I have a bunch of teams focused on building software that differentiates us as a business - the more time I can get them working on that stuff the better. Auth code doesn’t differentiate our product so I want to take that off the shelf as much as possible. There’s also an argument for “y’all are the experts in auth, so I want to be able to rely on that expertise in configuring, managing that functionality”.
In other words, less a tech question and more of a buy vs build question + org dynamics vs the dynamics of an individual developer doing a thing
Spring Boot 3 came out pretty recently, so it is correct that the quickstart and sample don’t demonstrate using Spring 6 and Spring Boot 3. We will work to get something in the backlog to update our quickstart and sample for Spring 6
The updating of documentation and samples in the quickstart is a separate conversation
If the team aren’t going to merge that PR, you’re essentially saying that:
Yes, we understand that you are blocked
Yes, we understand that in the immediate short term merging this PR will unblock you
We don’t want you to use our published library anymore, even though we don’t have an alternative for you at the moment.
Can you see how this traps me in no man’s land?
I’m happy to move from the library to another method, but it’s hard to hear that the team want me to do that without first providing the alternative.
Absolutely weapons-free to turn that library off, but please don’t block me when the Auth0 team could quickly fix the problem, such that I can migrate later when the preferred option has been released.
Sure totally understand you but I also want to share how we approach this. Before you guys actually created this topic there were some talks in the engineering team that is managing team that potentially that this library has been targeted for possible deprecation for quite some time.
As there were a couple of people recently reaching out to us regarding this library but also the PR that we are discussing the team needs to evaluate what will be further steps. As you can imagine in a company of that size working on so many different libraries, SDKs and other products it’s not a matter of just reviewing and merging one PR cause such decision brings specific outcomes and the team needs to simply analyze it in the long term.
As of now I’m not able to provide you with what you expect because of the mentioned reasons. As soon as I know something from the team I’ll make sure to relay it here. Sorry for the inconvenience!
I totally get it and I’m not upset!
I’ve had to make similar decisions in the past and am not trying to tie the hands of the maintaining team!
If there is no solution for now, I don’t like it, it’s not ideal, but I can accept it. But that means we probably ought to not mark a solution for this thread, so that folks who view it later don’t misinterpret and think there is a solution when there isn’t one. That’s all I’m saying
Having the clarity that this has been a conversation the team have been thinking about really helps, and helps ground this thread in that context.
Gotchya! I marked it as a solution for now so that others coming the the forum know what’s the current state for that. We constantly moderate those and change solutions etc. There are a lot of topics in the forum that are marked as solution but we clearly indicate that the engineering team is working on the solution and it should be there in the near future. Sorry for misleading!