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

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

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.


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


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


> Also, given the planned scope of changes, I think that split of
> eclipse-repository and eclipse-product packaging types needs to happen
> before any of this work.

I probably wasn't clear on this either: I'm doing the refactoring in my "free time", and hence I picked something I like to work on and that I think that Tycho will greatly benefit from in the long run. I agree that from the product point of view, the eclipse-product split is more important at the moment. But then, you can't control what people work on in open source projects...

Regards
Tobias