Restructure repository to move sdk components into a lower directory

[JonathanGiles]

To enable the introduction of other top-level components into the repo (e.g. the azure sdk BOM for Java, build tools, etc), it would likely make sense to move existing modules, for both management and data plane, into a subdirectory. This would clean the root level directory and prevent overload for users arriving at the github repo.

A proposed structure might take the form:

sdk\<service1>\client\src
sdk\<service1>\management\src
sdk\<service2>\client\src
sdk\<service2>\management\src

[weshaggard]

@jianghaolu do you have any issues with this structure change? Is there anyone else that should buy into this before I attempt to make that change?

[weshaggard]

Based on the proposed structure at https://github.com/Azure/azure-sdk/blob/master/docs/engineering-system/repo-structure.md we will change the repo structure to look like:

sdk\<package name>\README.md
sdk\<package name>\src\main
sdk\<package name>\src\test
sdk\<package name>\src\samples

Examples:

sdk\azure-mgmt-keyvault\README.md
sdk\azure-mgmt-keyvault\src\main
sdk\azure-mgmt-keyvault\src\test
sdk\azure-mgmt-keyvault\src\samples
sdk\azure-keyvault\README.md
sdk\azure-keyvault\src\main
sdk\azure-keyvault\src\test
sdk\azure-keyvault\src\samples

[JonathanGiles]

What do you think of dropping the 'azure-' part? It doesn't really add anything?

[JonathanGiles]

@weshaggard What's your time frame on doing this? For example, I know right now in the Java repo we have batch and event hubs pull requests. Do you want a freeze in additional pull requests after these are merged so that you can do the restructure, or are you looking at doing this at a later date? Fwiw, there are 242 other pull requests sitting in this repo too...just to make your life a little more difficult :-)

[weshaggard]

What do you think of dropping the 'azure-' part? It doesn't really add anything?

I agree it is redundant but it is still pretty nice to see the full package name in the path. Although with the path issues in Java repo in particular we can consider that.

What's your time frame on doing this?

There has been some additional feedback brought up for the general strategy so I want to address that before moving forward on doing this change. I don't expect we will actually make this change until we have general agreement across the repo's which I hope I can drive agreement over the next week or so and then we will schedule getting this work done.

Fwiw, there are 242 other pull requests sitting in this repo too...just to make your life a little more difficult :-)

:( - I might use this change as a good excuse to close and clean-up a lot of these pull requests.

[weshaggard]

The current proposal document can be found at https://github.com/Azure/azure-sdk/blob/master/docs/engineering-system/repo-structure.md.

The structure should look something like:

sdk\<service name>\<package name>\README.md
sdk\<service name>\<package name>\*src*
sdk\<service name>\<package name>\*tests*
sdk\<service name>\<package name>\*samples*

Examples:

sdk\keyvault\azure-mgmt-keyvault\README.md
sdk\keyvault\azure-mgmt-keyvault\src\main
sdk\keyvault\azure-mgmt-keyvault\src\test
sdk\keyvault\azure-mgmt-keyvault\src\samples
sdk\keyvault\azure-keyvault\README.md
sdk\keyvault\azure-keyvault\src\main
sdk\keyvault\azure-keyvault\src\test
sdk\keyvault\azure-keyvault\src\samples

Note in the guidelines document it calls out that for Java in particular we can use abbreviated package names for the directory to help deal with long path issues. So as we convert this repo we should keep that in mind and decide how we might want to name the directories, especially for the management libraries which usually have multiple versions.

A few things that we know needs to be updated when we make this restructuring:

1. The README files in the azure-rest-api-specs repo needs to be updated so the autorest tools can still function. We also need to stage the updates so that we don't disrupt too many in-flight PRs.
2. The build/CI scripts need to be updated so they understand the new structure. We should probably stage it so it understands both structures in the short term to enable incremental moving and minimize disruptions.
3. The documentation configuration system needs to be updated so it knows the new location of the README files and we don't break the documentation automation process.

[weshaggard]

#3073 updated the template project to match the new structure.

[mitchdenny]

Starting to get across what is required here. Can someone explain the backstory on the management libraries that have date folders? e.g. /keyvault/resource-manager/v2015_06_01. Assuming these are ARM API versions. Do we ship both versions of the packages or is one locked in time?

[weshaggard]

@jianghaolu can probably give you more information but my understanding is that we ship multiple parallel packages one for each API version.

I would suggest starting with the data-plane libraries and then working with folks on the management team to stage the move of the management libraries.