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