How can you avoid two ComponentFinderStrategies both finding the same component?

[deinspanjer]

I'm catching a bunch of components using the SpringAnnotations, but there are a few stragglers that I'm trying to catch using a RegexTypeMatcher.

I've run into a problem where one class that I'm trying to capture with the RegexTypeMatcher is also annotated with a Spring @component which causes the componentFinder to throw an IllegalArgumentException: A component named 'xxx' already exists for this container.

The scanning application continues on with the other scans, but it doesn't upload at the end. I was naively expecting that it would consolidate components found with more than one strategy within the same component. Do I have to manually try to avoid such a circumstance or am I maybe missing something?

[simonbrowndotje]

Older versions of the library used to silently ignore duplicate components, but I changed this behaviour a few months ago. Perhaps the easiest thing to do here is to add a flag (e.g. ignoreDuplicateComponents) onto the component finder strategy so that you can choose to ignore duplicate components, or not. Thoughts?

[deinspanjer]

So I think the typical end goal for any user of a finder strategy would be to end up with a list of all the components they might care about, ideally with all of the metadata and data about that component that it is possible to discover.

In this particular case, I believe there isn't really any additional data to be discovered about a Type that will become a component even if it is discovered by two separate finder strategies.

There might be a small bit of additional metadata, depending on if the strategy sets particular tags, technologies, etc. on the components. I'm thinking about the Spring Component finders in particular, but that might happen in others as well. A hypothetical case I can think of would be a Spring Component getting annotated with the Structurizr @component annotation.

So, my preference would be to merge any metadata where it can be merged. If it can't be merged, such as a name or description, then we'd have to consider either "a last found wins" or a priority based strategy. I don't think anyone would seriously complain about the last found wins resolution, and it would probably be a lot easier to implement.

[simonbrowndotje]

Perhaps the best way to deal with this is to allow people to customise what they want to do in the event that a duplicate component is found. I'm just adding some changes to support a pluggable strategy, of the form:

public interface DuplicateComponentStrategy {

    void duplicateComponentFound(Component component, String name, String type, String description, String technology);

}

You could then provide an implementation that did anything you wanted, with the default behaviour to throw a DuplicateComponentFoundException. Would that work for you?

[deinspanjer]

Yes, I think that would work fine. I'm working on my patched version of the spring finder strategies to just add dupes as supporting types since that is the majority of the cases I'm hitting at the moment.

[simonbrowndotje]

Done -> fd3fd68

[FreeWillaert]

Hi, I'm running into a bunch of DuplicateComponentFoundExceptions - not sure why yet, still investigating - but setting my own DuplicateComponentStrategy has no effect.
The errors are a.o. about Spring Repositories.

I'm not familiar with the codebase, but I think that in method beforeFindComponents of SpringComponentFinderStrategy the setDuplicateComponentStrategy for each item of componentFinderStrategies ?

[simonbrowndotje]

Thanks, I opened a new issue (#110) ... and pushed a fix that I think addresses it.

[FreeWillaert]

Hi, thanks for the fix! Any idea when you would push a new version to Maven Central?

[simonbrowndotje]

You're welcome! I'm planning a release later this week.