F: Only register version for the current project #97
Conversation
The main challenge is that currently the plugin is partially registering it self with subprojects, but not fully doing so. It should be updated to fully register and handle versioning everywhere or only do it for the project configured. This change moves it to only register for the currently configured project. I thought of making the existing behavior conditional, however even then it didn't feel like the correct change.
|
Split from original PR #94 |
|
Maybe this task should be moved to a separate plugin. WDYT? |
|
I think we should register it as it's useful. The correct fix should also be to categorize and add a description. We could also conditionally register it. It's useful to have a built in task to check the version. |
| // on | ||
| // sub projects. It would be nice to only define this once for all project in | ||
| // a multi-module project, however there are a few other considerations that | ||
| // need |
There was a problem hiding this comment.
I think we need to describe the problem to solve ("...other considerations that need to be made...").
There was a problem hiding this comment.
The current change scopes the plugin to the project in which is registered. This is the common pattern for most plugins. There are a few paths that could be followed.
- Leave as is where a version task is registered everywhere. I personally don't see the value in only registering part of the plugin. This registers the task, but does not apply the configuration aspects. If this is choose, the task should be registered conditionally and only afterEvaulate has completed. This would still allow the plug to be registered on other projects, which today it fails
- Take the change as is only register the plugin and it's tasks in the project requested. This is the pattern most plugins follow. It's the safest and easiest to get correct.
- Register and apply not only the version task, but also the versioning semantics to every project when in a multi-project. The challenge with this is that since the versioning happens during the configuration phase ordering is very important and getting this right will be difficult
There was a problem hiding this comment.
I would consider this a bug and not an enhancement, since as the plugin is currently authored it is unusable in a multi-project structure.
The main challenge is that currently the plugin is partially registering it self with subprojects, but not fully doing so. It should be updated to fully register and handle versioning everywhere or only do it for the project configured. This change moves it to only register for the currently configured project.
I thought of making the existing behavior conditional, however even then it didn't feel like the correct change.