-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Add some logging to codestarts #11803
Conversation
INFO:
DEBUG:
|
5bec52d
to
be69952
Compare
0e2c8c9
to
f39cbe9
Compare
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 like the emojis, but I think that if message-writer
is a new module, it should have its own package (io.quarkus.devtools.messagewriter
?)
...nt-projects/tools/message-writer/src/main/java/io/quarkus/devtools/DefaultMessageWriter.java
Outdated
Show resolved
Hide resolved
...endent-projects/tools/codestarts/src/main/java/io/quarkus/devtools/codestarts/Codestart.java
Show resolved
Hide resolved
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.
My biggest concern is about the removal of the MessageWriter classes in the platform-descriptor-api
. I think we should deprecate them first
...-common/src/main/java/io/quarkus/devtools/commands/handlers/CreateProjectCommandHandler.java
Show resolved
Hide resolved
@gastaldi IMO it's ok in a major release, keeping if we deprecate, I think we should have a policy and some automation about it to make sure it gets deleted at some point.. |
I strongly disagree. I'm not saying we should keep it forever (they will be removed at some point), but classes that belong to an API should be initially @deprecated to avoid breakage (that's the whole point of deprecating things really :) ) |
@gastaldi IMHO we need to be pragmatic, if this was an api massively used outside of our code, I would agree. But here this is a small tool (not part of the api itself).. I won't argue and @deprecate it, if you really feel unsafe with it. |
I remember using this API outside Quarkus (can't find the sources now). But I'll leave that final decision to @aloubyansky :) |
Changes are fine, deprecation needs to be discussed. Leaving that decision to Alexey
I mean this isn't public official api, those are internal api for our tooling. even if it breaks somewhere, well, worst case scenario you look at commit logs and see this was moved |
@maxandersen should we backport this or not? |
...ojects/tools/codestarts/src/main/java/io/quarkus/devtools/codestarts/CodestartProcessor.java
Outdated
Show resolved
Hide resolved
If you are backporting it you can't break the API. If you are targeting the next minor, you can break it. We've limited the platform compatibility range to a given minor. |
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.
Lambdas as debug args is too much. It looked to me like you could use debug(msg, args) instead.
@aloubyansky it is used for "complex" debug logs that requires processing (like list map and join). Don't forget that it is used by code.quarkus.io, I want to avoid the debug unnecessary processing, this is pretty common to provide a lambda for debug logs.. I really feed this is needed as I added a lot of debug logs. |
Perhaps I missed one, could you point me to the line in this PR where this is justified? |
Well you are right, there is not such call, I might have removed it in between.. I changed it all to format. |
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.
Thanks. But keep in mind that in case it's backported we need to keep backward compatibility.
Add logs to codestarts
Fixes #11084
There are a lot of modified files because of package renaming, the PR in itself is not that big.