Generate Managers and POMs for Azure SDK for Java#2446
Generate Managers and POMs for Azure SDK for Java#2446RikkiGibson wants to merge 9 commits intoAzure:masterfrom
Conversation
|
Can one of the admins verify this patch? |
|
@RikkiGibson, |
|
@azuresdkci add to whitelist |
| <parent> | ||
| <groupId>com.microsoft.azure</groupId> | ||
| <artifactId>azure-parent</artifactId> | ||
| <version>1.1.3-SNAPSHOT</version> |
There was a problem hiding this comment.
Do you think this version can go to the code generator? Same as the Beta annotation in the manager template.
There was a problem hiding this comment.
Would we pass a value from CodeGeneratorJvaf to the template indicating which version of Azure SDK for Java is being targeted?
There was a problem hiding this comment.
Yes - that would be ideal
There was a problem hiding this comment.
One day we can do a cmd argument but I think we can do that later
There was a problem hiding this comment.
The idea is that the generated manager class will be able to be merged into master without further editing.
There was a problem hiding this comment.
What's the input/output you'd like to see? Someone passes -AzureSDKVersion 1.1.3, then the pom gets 1.1.3-SNAPSHOT and the SinceVersion is V1_2_0?
|
Seems like you need to run |
|
Will need to troubleshoot my gulp and node setup to get |
|
Thank you. I took the steps you both mentioned and now I seem to be regenerating fine. |
|
@jianghaolu Seems like about 880 files were changed through regeneration--should I be committing all of that? Or just picking out Java.Azure.Fluent related stuff? |
|
I'm seeing a lot of: |
| var versionParts = targetVersion.Split('.'); | ||
| var minorVersion = int.Parse(versionParts[1]) + 1; | ||
| var result = "V" + versionParts[0] + "_" + minorVersion + "_0"; | ||
| return result; |
There was a problem hiding this comment.
one more nit picking - 2.0.0-SNAPSHOT will give me V2_1_0 but it should be V2_0_0 - you need to check the last digit to see if it's 0.
There was a problem hiding this comment.
Thanks for catching that. Should there be unit tests for this? Or we'll just run it and see if it did the right thing?
|
I merged in master and regenerated again. Now I'm here: |
|
Well, that's more like it -- although not unexpected. I guess we forgot to regenerated when we bumped the version number. Go ahead and add those changes into your PR. |
|
Did you want me to open a new PR, @fearthecowboy? |
|
@RikkiGibson, |
|
Whoops. hit wrong button. |
This constant should become a parameter at some point anyway.
|
@RikkiGibson I think there's still quite some diff - http://azuresdkci.cloudapp.net/job/autorest/5692/console |
|
@jianghaolu I'm not sure how to interpret the output from CI. Did I get something wrong when regenerating sources? |
|
@olydis -- we're seeing this variation again in the CI with generating source maps. O_o |
|
Seems to depend on weird details... maybe it's non-deterministic. Let's just not compare source maps in CI for now, even though there are differences they don't seem crucial. |
|
Should I be doing anything to make that happen? Or will you guys go in and tweak that after this PR? |
|
He's fixing the issue in the 2.0 branch -- You're going to need to rebase and issue a new PR there, but after that gets committed. |
Adds some templates to generate stub Manager classes. The generation of the Manager and POM is controlled by the RegenerateManager flag. Note that the path provided to Autorest in the Azure SDK for Java project has changed so that we can reasonably write the POM to the correct location.
The ServiceName property is something that we just expect to work most of the time due to the convention for paths in Azure, as well as the fact that we expect each service we generate code for to have at least one method.