Re: [tycho-dev] re, Deferring Dependency Resolution

["Oberlies, Tobias" <tobias.oberlies@xxxxxxx>]

> -----Original Message-----
> From: tycho-dev-bounces@xxxxxxxxxxx [mailto:tycho-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Igor Fedorenko
> Sent: Dienstag, 25. Oktober 2011 16:18
> To: tycho-dev@xxxxxxxxxxx
> Subject: Re: [tycho-dev] re, Deferring Dependency Resolution
> 
> 
> 
> On 11-10-25 7:16 AM, Oberlies, Tobias wrote:
> > Igor Fedorenko wrote:
> >> On 11-10-21 11:59 AM, Oberlies, Tobias wrote:
> >>> Igor Fedorenko wrote:
> >>>> My biggest concern is integration with non-tycho maven
> >>>> plugins. Currently, we have reasonably good story about
> >>>> all/most Tycho dependencies being pushed back to MavenProject,
> >>>> and this is simply not possible from a tycho mojo. We really
> >>>> need to hook into Maven dependency resolution logic to do this
> >>>> right, but I am not even sure if maven provides required
> >>>> extension points.
> >>>
> >>> What stops us from injecting the resolved OSGi dependencies into
> >>> the Maven model in one of the early lifecycle phases? (...)
> >>
> >> MavenProject dependencies are reset between mojo executions, at
> >> least in some cases. This is necessary to allow different mojo
> >> execution require different dependency scopes (i.e. compile vs
> >> test). Multithreaded build support is another consideration here,
> >> although I have not thought much about it yet.
> >
> > This sounds like a blocker. I don't fully understand why this has to
> > happen, but I hope this can be changed. The Maven mailing list is
> > probably a better place to discuss this though.
> >
> >
> 
> Dependency scopes are fundamental to Maven, so I don't expect any major
> change is possible. What is possible, at least in theory, is open up
> Maven dependency resolution implementation to allow Tycho plug
> project-specific log. I have not looked at this part of Maven core
> lately, so can't tell how much work is involved.

Could you try to produce such a case with the prototype [1]? The BuildOrderManager injects some dependencies in afterProjectsRead, but these dependencies are not complete. Others are added later, e.g. for nested jars or if there are transitive dependencies due to a re-exported package.

[1] https://github.com/oberlies/tycho/tree/bug353889_defer_resolution

> 
> >> In any case, whether dependency resolution happens in a mojo or in
> >> maven core is not terribly important. As long as resolver is a
> >> standalone component, we can hook it in maven core or call it from
> >> mojos directly.
> >
> > It may not be for Tycho, but it is a major difference for anyone who
> > wants to extend Tycho: Today you have to write a new build extension
> > and hook into Tycho via Plexus. Afterward the refactoring, it can be
> > as easy as filtering one of the metadata files on disk.
> >
> >
> 
> Can you elaborate on this? Tycho has to have code that implements
> dependency resolution logic and this logic needs to be plugged in Maven
> build lifecycle this way or another. Do I miss something here?

Yes, but currently it is very hard to do anything before this happens. If dependency resolution happens in the Mojo lifecycle, other plugins could manipulate the metadata files before this happens. I don't have this fully elaborated though. 


> >> This feels like too big a change to be done as one huge
> >> refactoring. Is there a way to split the work in smaller pieces or
> >> it really has to be all-or-nothing?
> >
> > This won't be a one-off thing. I'm keeping only the new stuff in a
> > branch, and pull out the refactorings (i.e. those things that really
> > just change the code structure) into master (e.g. 4dda65a, f1b27c08).
> > Having the afterProjectsRead activities structured in such a way that
> > they *could* be called from mojos, would probably already improve the
> > readability of the Tycho code, and this will be the first thing done
> > in master.
> >
> 
> Dependency resolver can be used from mojos already. This is how test
> runtime contents is calculated, for example. Or did I misunderstand you?

Yes, but you don't actually just call dependency resolution, but also the target platform is re-calculated.


Best Regards
Tobias