Currently, the source code of the library follows a flat folder structure: the classes follow normal OOP conventions, but the .java files themselves are all in one folder. This style has lead to an ever-increasing list of files that is difficult to understand at a glance.
We should refactor the library to follow Java conventions/best practices around directory structure, and organize logically similar files into subfolders similar to other MSALs such as MSAL.NET:
https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/tree/main/src/client/Microsoft.Identity.Client
For internal classes this refactor will be easy and should be initial first focus.
For public classes this would be a breaking change, as it changes how the class is referenced. There are potential ways to avoid a breaking change, such as the Apache Maven Shade Plugin, but this needs to be investigated more: https://maven.apache.org/plugins/maven-shade-plugin/
Currently, the source code of the library follows a flat folder structure: the classes follow normal OOP conventions, but the .java files themselves are all in one folder. This style has lead to an ever-increasing list of files that is difficult to understand at a glance.
We should refactor the library to follow Java conventions/best practices around directory structure, and organize logically similar files into subfolders similar to other MSALs such as MSAL.NET:
https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/tree/main/src/client/Microsoft.Identity.Client
For internal classes this refactor will be easy and should be initial first focus.
For public classes this would be a breaking change, as it changes how the class is referenced. There are potential ways to avoid a breaking change, such as the Apache Maven Shade Plugin, but this needs to be investigated more: https://maven.apache.org/plugins/maven-shade-plugin/