[
https://issues.apache.org/jira/browse/MRESOLVER-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MRESOLVER-248:
--------------------------------------
Description:
There is ongoing work to fundamentally change {{DependencyCollector}}
implementation in resolver.
Resolver was from beginning building dependency graph by doing "depth first"
(df) approach, and was downloading POMs sequentially during collection.
With work happing under MRESOLVER-240, MRESOLVER-247 and MRESOLVER-7, collector
is altered: is doing now "breadth first" (bf), implements skip-reconcile and
will have parallel POM download implemented, and maybe even more (like inter
collection cache?).
Still, IMHO letting both (original "df" and new "bf") coexists is technically
simple, and would allow us not only simpler comparison of the performance of
the two, but there is a possibility that there will be no "one size fit all"
solution, so having both knives in drawer is just a win-win. Also, this way we
do have a "baseline" to compare with easily: the "df" (original) collector vs
"bf" collector.
Ultimately, we MAY prove superiority of one over another, essentially leaving
only one collector implementation, as in that case this issue (and the
"coexistence indirection") should be just removed, and not enlist it in release
notes of upcoming 1.8.0 version.
was:
There is ongoing work to fundamentally change {{DependencyCollector}}
implementation in resolver.
Resolver was from beginning building dependency graph by doing "depth first"
(df) approach, and was downloading POMs sequentially during collection.
With work happing under MRESOLVER-240, MRESOLVER-247 and MRESOLVER-7, collector
is altered: is doing now "breadth first" (bf), implements skip-reconcile and
will have parallel POM download implemented, and maybe even more (like inter
collection cache?).
Still, IMHO letting both (original "df" and new "bf") coexists is technically
simple, and would allow us not only simpler comparison of the performance of
the two, but there is a possibility that there will be no "one size fit all"
solution, so having both knives in drawer is just a win-win. Also, this way we
do have a "baseline" to compare with easily: the "df" (original) collector vs
"bf" collector.
Ultimately, we MAY prove superiority of one over another, essentially leaving
only one collector implementation, as in that case this issue (and the
"coexistence indirection" should be just removed) and not enlist it in release
notes of upcoming 1.8.0 version.
> Make DF and BF collector implementations coexists
> -------------------------------------------------
>
> Key: MRESOLVER-248
> URL: https://issues.apache.org/jira/browse/MRESOLVER-248
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
> Reporter: Tamás Cservenák
> Priority: Major
>
> There is ongoing work to fundamentally change {{DependencyCollector}}
> implementation in resolver.
> Resolver was from beginning building dependency graph by doing "depth first"
> (df) approach, and was downloading POMs sequentially during collection.
> With work happing under MRESOLVER-240, MRESOLVER-247 and MRESOLVER-7,
> collector is altered: is doing now "breadth first" (bf), implements
> skip-reconcile and will have parallel POM download implemented, and maybe
> even more (like inter collection cache?).
> Still, IMHO letting both (original "df" and new "bf") coexists is technically
> simple, and would allow us not only simpler comparison of the performance of
> the two, but there is a possibility that there will be no "one size fit all"
> solution, so having both knives in drawer is just a win-win. Also, this way
> we do have a "baseline" to compare with easily: the "df" (original) collector
> vs "bf" collector.
> Ultimately, we MAY prove superiority of one over another, essentially leaving
> only one collector implementation, as in that case this issue (and the
> "coexistence indirection") should be just removed, and not enlist it in
> release notes of upcoming 1.8.0 version.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
