Re: [m2e-dev] granularity of lifecycle mapping resolution problems durin

[Milos Kleint <milos@xxxxxxxxxxxx>]

On Mar 6, 2011, at 3:00 AM, Igor Fedorenko wrote:

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.

agreed. I've been thinking about this over the weekend myself. The solution I came up with was to remove the individual project occurrences if they are all the same. Thus not give people a choice to select per-project which has felt like too much choice to me anyway.

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).

+1.

I've noticed that in some cases one plugin/goal appears multiple times currently. That's because the org.eclipse.m2e.core.project.configurator.MojoExecutionKey includes the executionId and lifecyclePhase into the equals/hashcode methods.

IMHO in most/all cases the executionId/lifecyclePhase doesn't really matter for the eclipse side of things (the mapping connector plugin)

In most cases even the version of the plugin is irrelevant (unless you execute the mojo, like we do with resources plugin)

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.

while this is definitely an improvement, for me the ideal scenario is following:

5. If user has both maven and wtp, there should be no mapping problems. At all. We should make sure that the bridging/mapping code is also installed.

We have basically two kinds of mapping/connector plugins. Either it's just a definition of what to do with the goal, or it maps m2e to some other plugins, like wtp, scala, aspectj. For the first group, I would say we shall ship with these by default. For the other group, the bridging shall be installed when both technologies are installed.

this is btw how it always worked in netbeans (the bridging plugins are installed automatically behind the scenes when all it's prerequisite dependencies are satisfied) and I've never heard any user complain that they didn't want the bridging installed. Obviously this is more of a p2 (hello pascal) feature request than m2e. m2e alone cannot possibly achieve that.

The question of people choosing mappings is elegantly solved this way by people choosing technologies to install. I have yet to see a good reason why users shall be allowed on a per project basis to choose their mappings/connectors.

Milos

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
_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-dev