Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[JENKINS-52304] Tweaks for JEP-201 #4

Merged
merged 1 commit into from
Jul 13, 2018

Conversation

jglick
Copy link
Member

@jglick jglick commented Jul 13, 2018

@@ -55,5 +55,10 @@
<artifactId>aws-credentials</artifactId>
<version>1.23</version>
</dependency>
<dependency>
<groupId>org.jenkins-ci.plugins</groupId>
<artifactId>structs</artifactId>
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previously picked up @Symbol from jenkins-core, which is dangerous for class loading reasons IIRC.


/**
* @author Carlos Sanchez
* @since
*
*/
@Symbol("aws")
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Inferred by chomping off pieces of the Class.simpleName, but best to be explicit.

@@ -64,7 +64,8 @@
/**
* Store the AWS configuration to save it on a separate file
*/
@Extension @Symbol("credentials")
@Symbol("awsCredentials")
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While credentials actually looks a bit nicer in the content of JEP-201, it is illegal for @Symbol generally as the ExtensionList here is GlobalConfiguration, not AbstractAwsGlobalConfiguration, so that would (probably) not be unique.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From JCasC point of view the symbol scope is the GlobalConfiguration category, so "credentials" is fine. But all yours.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issue is that it is ambiguous what a symbol scope will be. The Javadoc only promises that

symbol names are meant to be only unique within a specific extension point

which is fairly vague. Currently configuration-as-code does restrict the scope by category (I suppose in GlobalConfigurationCategoryConfigurator.describe), meaning it actually uses a different interpretation of the specification (since a GlobalConfigurationCategory is a classification but not an “extension point”). Other tools hewing more closely to the spec might call something like

SymbolLookup.find(GlobalConfiguration.class, symbol)

since that type is where the ExtensionPoint is declared.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indeed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants