Uploaded image for project: 'NPanday'
  1. NPanday
  2. NPANDAY-402 Add support to automatically attach and resolve PDB-symbols
  3. NPANDAY-598

Problem: resolving PDBs in a reactor module makes them a dependency for subsequent modules

    Details

    • Type: Sub-task
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.5.0-incubating
    • Component/s: Maven Plugins
    • Labels:
      None

      Issue Links

        Activity

        Hide
        lcorneliussen Lars Corneliussen added a comment -

        Victor Stefoglo I suspect the NPandayArtifactResolver is the same instance accross projects in the reactor - then the cache would mess things up.
        Tried <instantiation-strategy>per-lookup</instantiation-strategy>, but that didn't help. But I'm not sure if it is supported by the plexus version running.

        Show
        lcorneliussen Lars Corneliussen added a comment - Victor Stefoglo I suspect the NPandayArtifactResolver is the same instance accross projects in the reactor - then the cache would mess things up. Tried <instantiation-strategy>per-lookup</instantiation-strategy> , but that didn't help. But I'm not sure if it is supported by the plexus version running.
        Hide
        lcorneliussen Lars Corneliussen added a comment -

        fixed by configuring the resolver and dependencyresolution as instantiate per-lookup

        Show
        lcorneliussen Lars Corneliussen added a comment - fixed by configuring the resolver and dependencyresolution as instantiate per-lookup
        Hide
        brettporter Brett Porter added a comment - - edited

        Note: leaving this in place, but not sure it was the intended solution. Here's a comment from r1619669:

        This is probably not the ideal way to address this issue - it seems like
        the "cache" are actually collectors that should be scoped to the
        resolution request, and are storing instead of saving computation. The
        resolve cache is safe as it is only used to intersect with the resolved
        artifacts, but the dependency cache will grow as highlighted in this
        issue. These could be adjusted in future as a listener, or a processor on
        the resolved artifacts, or something passed in to the resolution request,
        allowing these to become singleton objects again.

        Show
        brettporter Brett Porter added a comment - - edited Note: leaving this in place, but not sure it was the intended solution. Here's a comment from r1619669: This is probably not the ideal way to address this issue - it seems like the "cache" are actually collectors that should be scoped to the resolution request, and are storing instead of saving computation. The resolve cache is safe as it is only used to intersect with the resolved artifacts, but the dependency cache will grow as highlighted in this issue. These could be adjusted in future as a listener, or a processor on the resolved artifacts, or something passed in to the resolution request, allowing these to become singleton objects again.
        Hide
        lcorneliussen Lars Corneliussen added a comment -

        I'm confused.

        Show
        lcorneliussen Lars Corneliussen added a comment - I'm confused.
        Hide
        brettporter Brett Porter added a comment -

        Hi Lars Corneliussen, basically what happened here was that the fix you'd applied got lost when I refactored. I noticed that, and reinstated it, and should now be working as before.

        However, I noted that this might not be the optimal solution in the long run - the scope is based on where it is instantiated rather than where it is used. Also, they are named as "caches", but they seem to be behaving as a way to collect information during a resolution run, that can be accessed after the resolution run, but are not to be used by subsequent resolution runs (hence the problem when retained where they accumulated information from previous resolutions).

        I don't think there is anything actionable here now - just wanted to add some information in case it's helpful for future reference.

        This is completely separate to NPANDAY-599, where we've also been discussing caching (which actually are keyed resolution caches for other scenarios), which I confusingly referenced this change before I understood what was happening there.

        Show
        brettporter Brett Porter added a comment - Hi Lars Corneliussen , basically what happened here was that the fix you'd applied got lost when I refactored. I noticed that, and reinstated it, and should now be working as before. However, I noted that this might not be the optimal solution in the long run - the scope is based on where it is instantiated rather than where it is used. Also, they are named as "caches", but they seem to be behaving as a way to collect information during a resolution run, that can be accessed after the resolution run, but are not to be used by subsequent resolution runs (hence the problem when retained where they accumulated information from previous resolutions). I don't think there is anything actionable here now - just wanted to add some information in case it's helpful for future reference. This is completely separate to NPANDAY-599 , where we've also been discussing caching (which actually are keyed resolution caches for other scenarios), which I confusingly referenced this change before I understood what was happening there.
        Hide
        lcorneliussen Lars Corneliussen added a comment -

        Thanks for the clarification. Maybe ResolutionContext or ResolvedAttachedArtifactsCollector would be better names.

        Show
        lcorneliussen Lars Corneliussen added a comment - Thanks for the clarification. Maybe ResolutionContext or ResolvedAttachedArtifactsCollector would be better names.

          People

          • Assignee:
            Unassigned
            Reporter:
            lcorneliussen Lars Corneliussen
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development