On 08/06/2022 23:03, Robert Scholte wrote:
This is already a huge improvement as imported boms now hides this
information.
Thanks!
I do see room for more improvements, though (even though they could be
considering as minor as this already solves a critical issue)
From another example I picked one of the longest lines:
<version>2.16.1</version> <!--
io.zipkin.reporter2:zipkin-reporter-bom:2.16.1, line 149 from
io.zipkin.brave:brave-bom:5.13.2 from
org.springframework.cloud:spring-cloud-sleuth-dependencies:3.0.4 from
org.springframework.cloud:spring-cloud-dependencies:2020.0.4-->
Suppose you want to use a different version of this zipkin dependency,
what should you do? The first thing is to check is if you can upgrade
spring-cloud-dependencies. The focus should be on that dependency.
Even though io.zipkin.reporter2:zipkin-reporter-bom:2.16.1, line 149 is
the most exact location, what's probably more important from a developer
perspective is the preferred location to make a change in your pom.
That would likely be
org.springframework.cloud:spring-cloud-dependencies:2020.0.4.
IMO that should be the first part of the line (instead of scrolling to
the right). This implies reverting the order, so instead of .. from ..
from .., I'd prefer .. to .. to ..
This should be a relatively simple task. I think we can isolate this in
the M-H-P. I feel it should be part of the first release - reversing the
display order later would be confusing to users.
Now that we know the org.springframework.cloud:spring-cloud-dependencies
dependency needs to be updated, it would be great if it shows the
linenumber in the pom.
We might run into problems if this was inherited via a parent pom, in
which case we should make clear which parent shoould be changed.
Agreed - I haven't checked that use case yet, but I see how it could be
relevant and useful. I think this could be postponed to a later release
if it turns out to be hard to implement.
I'm already very pleased with the current results. If you agree with me
you can make separate tasks of it and decide if they should be come part
of the same release or not.
I consider it finetuning, although adjusting the order later might
result in a huge shock as you suddenly need to read it the other way
around.
Great minds... :-)
great work,
Thanks again!
Robert
------ Oorspronkelijke bericht ------
Van "Maarten Mulders" <[email protected]>
Aan "Maven Developers List" <[email protected]>
Datum 7-6-2022 17:46:41
Onderwerp [MPH-183] effective-pom + verbose should show path to source
Hi all,
Over the past months, I have been working on an enhancement [1] for
the Maven Help Plugin. The enhancement is about the effective-pom
goal. If you pass it the 'verbose' parameter, it will include inline
comments saying "this line of the effective pom is caused by this line
in a different pom":
<dependency>
<groupId>org.example</groupId> <!--
org.example:mng-7344-bom-c:1-SNAPSHOT, line 17 -->
<artifactId>mng-7344-dep-x</artifactId> <!--
org.example:mng-7344-bom-c:1-SNAPSHOT, line 18 -->
<version>2</version> <!-- org.example:mng-7344-bom-c:1-SNAPSHOT,
line 19 -->
</dependency>
This is not so useful when you have a long path of POMs referring to
each other. It will only show the last POM of that trail, but not the
intermediate POMs. This makes it hard for users to understand how
their effective POM was constructed. In the enhanced version,
help:effective-pom -Dverbose would show something like this:
<dependency>
<groupId>org.example</groupId> <!--
org.example:mng-7344-bom-c:1-SNAPSHOT, line 17 from
org.example:mng-7344-bom-a:1-SNAPSHOT from
org.example:mng-7344-project:1-SNAPSHOT-->
<artifactId>mng-7344-dep-x</artifactId> <!--
org.example:mng-7344-bom-c:1-SNAPSHOT, line 18 from
org.example:mng-7344-bom-a:1-SNAPSHOT from
org.example:mng-7344-project:1-SNAPSHOT-->
<version>2</version> <!-- org.example:mng-7344-bom-c:1-SNAPSHOT,
line 19 from org.example:mng-7344-bom-a:1-SNAPSHOT from
org.example:mng-7344-project:1-SNAPSHOT-->
</dependency>
(I'm sorry, the output is hard to read in a plain-text email; a
formatted version is available in the JIRA ticket [1].)
This enhancement requires changes in three projects:
1. Maven Help Plugin
2. Maven Core
3. Modello
Now that the proof of concept is there, I'd like to ask: is this an
enhancement we want to incorporate into Maven? If so, I'll start by
polishing the code a bit, and then open three separate merge requests.
We can discuss the implementation there.
One particularly important thing to mention is that I did _not yet_
pay attention to backward compatibility of the Maven Help Plugin. I
believe we can do this in a decent way - it wasn't the first priority
for the proof of concept.
I'm looking forward to hearing your thoughts on this.
Thanks,
Maarten
[1] https://issues.apache.org/jira/browse/MPH-183
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
