Skip to content

feat(maven): Optional android config - #271

Merged
iker-barriocanal merged 9 commits into
masterfrom
iker/ref/maven-android-optional
Aug 23, 2021
Merged

feat(maven): Optional android config#271
iker-barriocanal merged 9 commits into
masterfrom
iker/ref/maven-android-optional

Conversation

@iker-barriocanal

Copy link
Copy Markdown
Contributor

The maven target is responsible for releases related to Maven. Currently, the Android configuration is required, but there are scenarios where it isn't used (e.g. https://github.com/getsentry/sentry-android-gradle-plugin). This PR makes the android configuration optional.

@iker-barriocanal iker-barriocanal self-assigned this Jul 22, 2021
Comment thread CHANGELOG.md Outdated
Comment thread src/targets/maven.ts
@marandaneto

Copy link
Copy Markdown
Contributor

it prints Did not find a BOM for every package, maybe let's change to: found a BOM when it's a BOM, since the majority of the packages aren't a BOM, this gives the impression that something is off, but it's the correct behavior.

Comment thread src/targets/maven.ts Outdated
Comment on lines +96 to +98
this.logger.warn(
'You may need the Android configuration and it was not found in the configuration file.'
);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

not sure if this should be a warn level since the android config is optional.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I find anything below a warn to not be enough when an android release may file because the config is missing.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Then this should be info or even less and then we should have a hard-fail when this is required but missing.

@marandaneto

Copy link
Copy Markdown
Contributor

@iker-barriocanal @BYK there are a few comments here but the PR does whats supposed to do, feel free to address them, or not and merge and release Craft, I can confirm that it works :)

@marandaneto

Copy link
Copy Markdown
Contributor

it prints Did not find a BOM for every package, maybe let's change to: found a BOM when it's a BOM, since the majority of the packages aren't a BOM, this gives the impression that something is off, but it's the correct behavior.

btw it already prints found BOM, so just removing Did not find a BOM or lowering log level would be fine.

@iker-barriocanal iker-barriocanal changed the title ref(maven): Optional android config feat(maven): Optional android config Aug 17, 2021

@BYK BYK left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Definitely an improvement over the existing state so approving. That said I have some questions, concerns, and suggestions.

mavenSettingsPath: DEFAULT_OPTION_VALUE,
mavenRepoId: DEFAULT_OPTION_VALUE,
mavenRepoUrl: DEFAULT_OPTION_VALUE,
android: false,

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Why not null or undefined? I'm wary about variable-type fields.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

My thinking about what this config field should answer is "I don't want to configure Android".

  • I think of null as "there's no Android config". Why isn't there an Android config? Have you forgotten about it? This, to me, is like not answering a question.
  • I think of undefined as "the Android config hasn't been defined". Why don't you define it then, if it's a config file? Do you want to set an android config or not? This, to me, is like giving a very ambiguous answer to a question.
  • I think of false as "I don't want to set an Android config, but I'm saying it". This, to me, is like saying you don't want to set the configuration (answering with a nonambiguous answer).

Thus, using false seems the most appropriate for me. Do you have a different opinion about any (or all) of them? What do you think? Is it a best practice to use another type? (I might have thought about the field like isAndroid too.)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I understand and mostly agree with the reasoning. But requiring to be explicit can lead to unnecessary frustration or repetition, especially in configurations like these. I'm almost thinking about it might be better to split android and maven targets and make them share a common core to address your concerns here.

Comment thread src/targets/__tests__/maven.test.ts Outdated
Comment thread src/targets/__tests__/maven.test.ts Outdated
Comment thread src/targets/__tests__/maven.test.ts Outdated
Comment thread src/targets/__tests__/maven.test.ts Outdated
Comment thread src/targets/__tests__/maven.test.ts Outdated
Comment thread src/targets/__tests__/maven.test.ts Outdated

@BYK BYK left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Looks good with the updates so unblocking.

I'm still not sold on the "explicitly set to false" idea though. If I only care about Java packages w/o Android, why should I need to know (or worse, guess) to set android to false? Or does it even make sense setting android: false when it is actually required?

@iker-barriocanal
iker-barriocanal merged commit 76fd10d into master Aug 23, 2021
@iker-barriocanal
iker-barriocanal deleted the iker/ref/maven-android-optional branch August 23, 2021 10:11
@BYK BYK added this to the Added Maven Target milestone Sep 14, 2021
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