[
https://issues.apache.org/jira/browse/MNG-7510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Läubrich updated MNG-7510:
------------------------------------
Description:
Currently Tycho injects some dependencies into the maven model at a very early
state. As this computation is time consuming, it has several drawbacks:
# Even if one executes some goals that do not require the resolving of these
artifacts, the computation is performed
# If computation fails for one module the whole build fails, so flags like
-fae are not really usable and implementing such support directly is very
complex
# If running a parallel build, the build can't start unless we have computed
all modules
For this I have now prototype a new approach that only computes the absolute
necessary parts and delays the heavy computation into a mojo called in the
initialization phase of the life-cycle. This works quite well but currently
requires some hacks:
# I need to force maven to throw away all resolved state because otherwise
later injected dependencies are missing, I'm currently use
project.setDependencyArtifacts(null); for this but of course it feels like
waste of throw away all the data and rely on internal behavior of maven
# other maven tools are not aware of this (e.g. dependency:list) and if I
execute such one, the user needs to add an explicitly manual mojo execution
Because of this, I like to discuss/suggest a way for a project scoped extension
to participate in the collection of DependencyArtifacts.
For now, I found two possible "vectors":
# DefaultProjectArtifactFactory currently converts Artifact out of the
Dependency and it seems one might want to hook in here to provide additional
Artifact/Dependency, but it seems to be to narrow to be useful in general.
# LifecycleDependencyResolver.resolveProjectDependencies(MavenProject,
Collection<String>, Collection<String>, MavenSession, boolean, Set<Artifact>)
seems the most suitable place as it actually do the computation and checks.
# LifecycleModuleBuilder#buildProject is actually the most valuable / generic
place I think as it would also allow other use-cases where one want to get
notified about a project build started, and as
AbstractMavenLifecycleParticipant is abstract an extension here would even be
backward-compatible and wont require any new interfaces/services/... to be
created.
I'm in favor of option (3) but still wanted to still explain how I got there of
course and feedback/ideas are appreciated! I'll try to provide a PR for (3) as
well so one could maybe better discuss on the actual code changes.
Beside that there is also org.apache.maven.execution.ProjectExecutionListener
that seem to serve similar purpose, but it javadoc says:
This interface is part of work in progress and can be changed or removed
without notice.
was:
Currently Tycho injects some dependencies into the maven model at a very early
state. As this computation is time consuming, it has several drawbacks:
# Even if one executes some goals that do not require the resolving of these
artifacts, the computation is performed
# If computation fails for one module the whole build fails, so flags like
-fae are not really usable and implementing such support directly is very
complex
# If running a parallel build, the build can't start unless we have computed
all modules
For this I have now prototype a new approach that only computes the absolute
necessary parts and delays the heavy computation into a mojo called in the
initialization phase of the life-cycle. This works quite well but currently
requires some hacks:
# I need to force maven to throw away all resolved state because otherwise
later injected dependencies are missing, I'm currently use
project.setDependencyArtifacts(null); for this but of course it feels like
waste of throw away all the data and rely on internal behavior of maven
# other maven tools are not aware of this (e.g. dependency:list) and if I
execute such one, the user needs to add an explicitly manual mojo execution
Because of this, I like to discuss/suggest a way for a project scoped extension
to participate in the collection of DependencyArtifacts.
For now, I found two possible "vectors":
# DefaultProjectArtifactFactory currently converts Artifact out of the
Dependency and it seems one might want to hook in here to provide additional
Artifact/Dependency, but it seems to be to narrow to be useful in general.
# LifecycleDependencyResolver.resolveProjectDependencies(MavenProject,
Collection<String>, Collection<String>, MavenSession, boolean, Set<Artifact>)
seems the most suitable place as it actually do the computation and checks.
# LifecycleModuleBuilder#buildProject is actually the most valuable / generic
place I think as it would also allow other use-cases where one want to get
notified about a project build started, and as
AbstractMavenLifecycleParticipant is abstract an extension here would even be
backward-compatible and wont require any new interfaces/services/... to be
created.
I'm in favor of option (3) but still wanted to still explain how I got there of
course and feedback/ideas are appreciated! I'll try to provide a PR for (3) as
well so one could maybe better discuss on the actual code changes.
> Enhance AbstractMavenLifecycleParticipant to watch for buildProject events
> --------------------------------------------------------------------------
>
> Key: MNG-7510
> URL: https://issues.apache.org/jira/browse/MNG-7510
> Project: Maven
> Issue Type: New Feature
> Reporter: Christoph Läubrich
> Priority: Major
>
> Currently Tycho injects some dependencies into the maven model at a very
> early state. As this computation is time consuming, it has several drawbacks:
>
> # Even if one executes some goals that do not require the resolving of these
> artifacts, the computation is performed
> # If computation fails for one module the whole build fails, so flags like
> -fae are not really usable and implementing such support directly is very
> complex
> # If running a parallel build, the build can't start unless we have computed
> all modules
> For this I have now prototype a new approach that only computes the absolute
> necessary parts and delays the heavy computation into a mojo called in the
> initialization phase of the life-cycle. This works quite well but currently
> requires some hacks:
> # I need to force maven to throw away all resolved state because otherwise
> later injected dependencies are missing, I'm currently use
> project.setDependencyArtifacts(null); for this but of course it feels like
> waste of throw away all the data and rely on internal behavior of maven
> # other maven tools are not aware of this (e.g. dependency:list) and if I
> execute such one, the user needs to add an explicitly manual mojo execution
> Because of this, I like to discuss/suggest a way for a project scoped
> extension to participate in the collection of DependencyArtifacts.
> For now, I found two possible "vectors":
> # DefaultProjectArtifactFactory currently converts Artifact out of the
> Dependency and it seems one might want to hook in here to provide additional
> Artifact/Dependency, but it seems to be to narrow to be useful in general.
> # LifecycleDependencyResolver.resolveProjectDependencies(MavenProject,
> Collection<String>, Collection<String>, MavenSession, boolean, Set<Artifact>)
> seems the most suitable place as it actually do the computation and checks.
> # LifecycleModuleBuilder#buildProject is actually the most valuable /
> generic place I think as it would also allow other use-cases where one want
> to get notified about a project build started, and as
> AbstractMavenLifecycleParticipant is abstract an extension here would even be
> backward-compatible and wont require any new interfaces/services/... to be
> created.
>
> I'm in favor of option (3) but still wanted to still explain how I got there
> of course and feedback/ideas are appreciated! I'll try to provide a PR for
> (3) as well so one could maybe better discuss on the actual code changes.
>
> Beside that there is also org.apache.maven.execution.ProjectExecutionListener
> that seem to serve similar purpose, but it javadoc says:
> This interface is part of work in progress and can be changed or removed
> without notice.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
