We have basic support for being able to exclude resource distributions, but it is mostly manual. We need some more automation for this to go smoothly.
Make the ICU4JResourceConverter tool into a dotnet tool. This is blocked by the fact we depend on the .NET Framework version of al.exe that isn't cross OS (#82).
Automate the process of unpacking the icu4j.jar file from Maven, giving the user a choice between packing satellite assemblies or resource files.
Add better tooling for being able to deploy a class library that depends on a custom resource package.
a. We need to ensure the version of the custom NuGet package stays aligned with the original ICU4N build.
b. The end consumer should be able to override the custom resource NuGet package with either the default or another custom resource package. This can be done by packing a buildTransitive/<assemblyName>.targets file that has a PackageReference to the custom NuGet package.
Copying the ICU4N.targets file worked pretty well. We just need to automate the process of packing a copy of this file as buildTransitive/<assemblyName>.targets in the appropriate scenarios (giving the user the ability to opt in or out of this) when a custom distribution is involved and to reference the custom package name.
We have basic support for being able to exclude resource distributions, but it is mostly manual. We need some more automation for this to go smoothly.
buildTransitive/<assemblyName>.targetsfile that has a PackageReference to the custom NuGet package.Copying the
ICU4N.targetsfile worked pretty well. We just need to automate the process of packing a copy of this file asbuildTransitive/<assemblyName>.targetsin the appropriate scenarios (giving the user the ability to opt in or out of this) when a custom distribution is involved and to reference the custom package name.