IVY-1662: collect updates by conf and check transitive on old dependency

[eric-milles]

The ivy:checkdepsupdate task should examine dependencies by conf so that it does not report on a dependency in another conf that has an update. For example, if org.dom4j:dom4j:2.2.0 is in "conf1" and com.github.spotbugs:spotbugs-ant:4.9.3 is in "conf2" there is a transitive dependency to org.dom4j:dom4j:2.1.4. With <ivy:checkdepsupdate conf="conf1" revisionToCheck="latest.release" showTransitive="false" /> there is a line "org.dom4j#dom4j 2.1.4 -> 2.2.0".

https://issues.apache.org/jira/browse/IVY-1662

[maartenc]

The output is now grouped by configuration.
To keep this more 'backwards compatible', would it make sense to not do this?
Or maybe put this new grouping feature behind an extra attribute in the ivy:checkdepsupdate task?

[eric-milles]

The old behavior was to include dependnecies from other confs, so this is a step forward in preventing leakage. IMO it needs to be grouped in this way since the confs may have different inclusions, exclusions and resolution. I'm not sure what backwards compatible concern there is for a task that logs. The conf labels are the only addition.

[eric-milles]

@maartenc I split the prep. and refactor out from the main change. You can review and cherry-pick this first: dc15671

If you want, I can create a separate PR for it. If you are oaky with the main change then I can make this PR ready for review and you would then just use GH UI "Rebase and merge" to preserve the separate commits.

Otherwise, I suppose you could cherry-pick both changes to your own branch and add the release notes entry. Or do you want me to include release notes entry with each bug fix?

[eric-milles]

I do not have a test that shows the behavior change. The scenario described above works like this:

<ivy-module>
    <info organisation="foo" module="bar" />
    <configurations>
        <conf name="main" />
        <conf name="build" visibility="private"
          description="Artifacts necessary for Ant build" />
    </configurations>
    <dependencies defaultconf="main" defaultconfmapping="*->master,runtime()">
        <dependency org="org.apache.commons" name="commons-lang3" rev="3.18.0" />
        <dependency org="net.sourceforge.cobertura" name="cobertura" rev="2.1.1" conf="build" />
    </dependencies>
</ivy-module>

<ivy:checkdepsupdate conf="main" revisiontocheck="latest.release" />

Before

[ivy:checkdepsupdate] Dependencies updates available :
[ivy:checkdepsupdate] 	org.apache.commons#commons-lang3	3.3.2 -> 3.18.0

After

[ivy:checkdepsupdate] Dependencies updates available :
[ivy:checkdepsupdate] All dependencies are up to date

[eric-milles]

Given a few confs with updates, the output looks like this now:

[ivy:checkdepsupdate] Dependencies updates available :
[ivy:checkdepsupdate] 	conf: build/checkstyle
[ivy:checkdepsupdate] 	com.puppycrawl.tools#checkstyle	11.0.0 -> 11.0.1
[ivy:checkdepsupdate] 	conf: build/findbugs
[ivy:checkdepsupdate] 	org.slf4j#slf4j-simple	2.0.17 -> 99.0.globalexclude
[ivy:checkdepsupdate] 	conf: master
[ivy:checkdepsupdate] 	org.apache.xmlbeans#xmlbeans	3.1.0 -> 5.3.0
[ivy:checkdepsupdate] 	org.springframework.ws#spring-ws-core	4.0.15 -> 4.1.1
[ivy:checkdepsupdate] 	org.apache.velocity#velocity-engine-core	2.3 -> 2.4.1

[eric-milles]

@maartenc I restored the two test assertions you commented on and then they change in the second commit to demonstrate behavior differences. You can review each commit separately using the Commits tab. If you're okay with both, GH UI provides a means to merge while preserving the separate commits -- just don't use "squash" option.

[maartenc]

Yes I saw it, it already looked at it and thought it was ok.
Just didn't had the time yet to integrate that refactor commit into the codebase.
But I did it now, so now I can start looking at thecommit that actual fixes something 😅

[eric-milles]

@maartenc Hope all is well. I would like to get this and a few other bugs fixed. I've been left in a holding pattern since September.