[m2e-dev] granularity of lifecycle mapping resolution problems during im

[Igor Fedorenko <igor@xxxxxxxxxxxxxx>]

While working on discovery and installation of m2e extensions during
project import, I've come to realise that there are several more or less
sensible ways to group or aggregate multiple similar and/or related
lifecycle mapping problems.

From least grouping/aggregation to most

1. Treat each project/packaging-type and project/plugin-execution as a
separate problem, like my original prototype did. I think we all agreed
this provides way too much details to be useful, so lets skip this one ;-)

2. Group problems by packaging-type and plugin-execution but let the
user see individual occurrences and possibly select different solutions
for individual occurrences. Currently implemented in master. Gets
confusing if some of the occurrences have lifecycle mapping in pom.xml
while others don't. Not a likely scenario, though. I also think list of
individual occurrences is rather confusing and probably not useful in
most of cases.

3. Treat each unique mapping problem as one, only allow one solution for
all occurrences of each mapping problem, do not show individual problem
occurrences to the user or at least do not show by default. So, if a
project uses modello xpp3-reader and xpp3-writer goals, the user will
see them as two separate mapping problems regardless how many projects
use these goals. (have local prototype).

4. Try to aggregate individual mapping problems based on plugin GA and
available solutions. For example, treat all modello goals covered by
modello project configurator as one mapping problem. Another example,
treat packaging=war and war-plugin goals supported by m2e-wtp as one
mapping problem. I think this will be the most user-friendly solution,
but I am not sure we'll be able to make it work reliably in all cases.


After playing with this last few days, I personally think #3 (i.e. deal
with unique resolution problems) is the best we can do for Indigo, while
#4 seems like a fine future research project.

What do you think?

--
Regards,
Igor