Provided scope dependencies picked up in some cases but not others

[rootAvish]

Issue Overview

I am getting conflicting behavior around dependency resolution for the "provided" scope packages.

Expected Behaviour

Either the "provided" scope packages should be ignored in all cases or picked in all cases.

Current Behaviour

"Provided" scope packages are picked in some cases and ignored in others.

Steps To Reproduce

1. Generate stack report for: https://github.com/vaadin/dashboard-demo
   The "provided" scope dependency javax.servlet:javax.servlet-api is analyzed
2. Generate stack report for: https://github.com/mttkay/ignition
   The "provided" scope dependency com.google.android:android is not analyzed and neither unknown

/cc @samuzzal-choudhury

[stevengutz]

@GeorgeActon @samuzzal-choudhury Please stop changing the priorities. These are defined by/for the business and it looks like you are confusing then with severity. This particular defect has no significant bearing on the business so it is a P4

[samuzzal-choudhury]

@stevengutz I understand that a bug's priority has to be set to P2 if the team thinks that it has a business impact and requires a fix for that during a sprint. Whereas, I see severity as the parameter that defines the impact of the bug on an application's functionality and user experience. Correct me if I am wrong.

cc: @GeorgeActon @sivaavkd

[stevengutz]

@samuzzal-choudhury I don't think anyone is wrong - your definitions for severity and priority are right on target. So my apologies.

In fact, I spoke to @GeorgeActon and he convinced me that your assessment is probably "right-er" than mine. My suggestion to George was that priority values (except for a default P4 when the bug is created) should probably be adjusted by he and @sivaavkd just so it's clear that someone who maps closer to the business need was the one making the change. Makes me nervous when engineers are deciding business priorities ;-)

[abs51295]

This issue is produced due to mercator giving empty results for the dependencies included inside <projects></projects> tag, which in turn is caused by the use of mvn help:effective-pom while generating effective pom for root level manifest file, since that in turn aggregates all the poms of modules and pastes it in the effective pom for root. Have a look here: https://gist.github.com/abs51295/85c0052a8f9c98d5ce07a97bb1be19cb.

On the other hand, on the build side and while generating stack report on workspace level we use mvn io.github.stackinfo:stackinfo-maven-plugin:0.2:prepare which does things differently and generates poms at individual module level (Example: https://gist.github.com/abs51295/cdc3eb5112ea1272d1923e079fc696e5). The key thing is that this plugin doesn't support generating effective pom for a single pom passed as a parameter using the -f flag. So either we just run this command irrespective of whether we are trying to generate stack report on workspace vs individual manifest file, which will add overhead, but if the user has already done mvn install or if the user has already generated a stack report on workspace previously, then this should be quick.

What are your thoughts @samuzzal-choudhury @msrb @miteshvp @invincibleJai ?

[invincibleJai]

I am no java expert, I'll suggest validate it even with effective pom generated in IDEs like eclipse and take a decision. Will work based on that.

As it's recommended in docs as well https://maven.apache.org/plugins/maven-help-plugin/effective-pom-mojo.html

try stack-analyses on both and validate the difference i.e are we happy with all info provided in stack report.

[msrb]

As discussed on mattermost, poms which start with <projects> element are invention of the help plugin and are not valid Maven poms.

I'd suggest switching to stackinfo-maven-plugin - we can implement missing functionality there.

Note there is a reason why we use stackinfo-maven-plugin in pipelines: output from help:effective-pom can contain user credentials as it includes contents of Maven's settings files.

[abs51295]

@invincibleJai can you make the necessary changes in VS code extension?

[invincibleJai]

@abs51295 this is an enhancement we need to plan for it, am not sure about 154. We can accommodate if it's really urgent. And it would be good if we can make it (stackinfo-maven-plugin ) support one particular pom as well as @msrb suggested.

I'd suggest switching to stackinfo-maven-plugin - we can implement missing functionality there.

CC @samuzzal-choudhury @miteshvp

[miteshvp]

@invincibleJai - sounds good.