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
feat(maven-plugin): log informative message when maven jkube goals are skipped #1142 #1193
feat(maven-plugin): log informative message when maven jkube goals are skipped #1142 #1193
Conversation
0de8027
to
b1f318d
Compare
b1f318d
to
adb2b15
Compare
a test seems to be failing:
|
There is a failing test because I introduced mojoExecution that is null in one of the existing test. Trying to fix it. |
Although the current log message is very good. While testing I had a feeling if we really need to do the extra effort of specifying goal name in skip message since the goal getting executed is specified by maven on a line above in logs. Right now we're doing this:
Does it make sense to just keep a simple message like this? If not, we're good with current implementation as well.
|
from the user perspective |
okay, let's keep it the way it is 👍 |
adb2b15
to
f98a290
Compare
Codecov Report
@@ Coverage Diff @@
## master #1193 +/- ##
============================================
+ Coverage 49.57% 49.60% +0.02%
- Complexity 3656 3663 +7
============================================
Files 455 455
Lines 20625 20631 +6
Branches 2814 2814
============================================
+ Hits 10225 10234 +9
+ Misses 9315 9311 -4
- Partials 1085 1086 +1
Continue to review full report at Codecov.
|
the |
@Override | ||
public final void execute() throws MojoExecutionException, MojoFailureException { | ||
init(); | ||
if (!canExecute()) { | ||
log.info("`%s` goal is skipped.", mojoExecution.getMojoDescriptor().getFullGoalName()); | ||
return; | ||
} | ||
doExecute(); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand that this reorganization is similar to what was discussed in #1198 (review)
However, there's already an issue to cover this (#147). Code reorganization at this point might make it harder to refactor later on. Especially since this class now has an execute
, executeInternal
, and doExecute
methods with no clear separation of purposes (at least semantically speaking).
For the current PR I would rather not change (complicate) more the structure of the class (although I do agree the execute method is more readable now), end delay that effort until the whole refactor (+ maybe removal) of the class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
semantically:
execute
is the public methodexecuteInternal
is the execution implementation extended by subclasses -> should be abstract- I added
doExecute
which is the execution code from the abstract class. executed if not skipped
Basically at the end of the day after refactoring
execute()
should call doExecute
that should call executeInternal
.
I am open to a better naming or suggestions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand what each does, but there's no clear separation of concerns. If all of the methods are executing stuff, why are you separating two of them... i.e. naming is fine, but separation isn't.
Anyway, this refactor right now introduces more burden if we want to tackle #147, which is the cleaner approach. The point here would be to add the simple log message and try to move on without changing too much what we already have. IMO it would be better to spend the time creating tests that would ensure a successful latter refactor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I initially refactored because it was easier to test.
I refactored again. That should help to tackle #147 IMHO
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I might not have explained myself clear.
If the refactor is required to improve or ease the test scenarios, then it's OK, period.
If the refactor or reorganization is to clean up, improve readability etc. what I was trying to say is that this effort will be wasted if we finally implement 147 (which we should). It might even complicate things further. Efforts should be pushed towards testing the current functionalities of the final Mojos so that the upcoming refactor can be done in a safe way.
Anyway, it's OK as it is. Let's move on.
5a4634b
to
c82d91d
Compare
@manusa should be ok to merge ? |
I'm not sure if this one can be removed: |
let me give a try |
…e skipped eclipse-jkube#1142 Signed-off-by: Sun Tan <sutan@redhat.com>
…ractDockerMojo for readability Signed-off-by: Sun Tan <sutan@redhat.com>
c82d91d
to
a58d233
Compare
Kudos, SonarCloud Quality Gate passed! |
fixed |
Description
Log informative message when maven jkube goals are skipped.
part of #1142
Type of change
test, version modification, documentation, etc.)
Checklist