[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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.
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?
And since you mentioned filtering, can you elaborate how you plan to
support it too? It sounds like you want to store p2 iu and artifact
metadata on disk. It is not clear to me when the metadata is going to be
written and red back. Will Tycho provide API to access the metadata (in
which case file on disk or not is largely irrelevant) or direct file
access will be the only way to "massage" the metadata?
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?
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...
eclipse-repository/eclipse-product split may introduce additional
requirements for Tycho dependency resolver and the way p2 metadata is
managed during the build, so I think it makes sense to understand these
requirements before reworking the resolver.
And, to be clear, I am not trying to control what you do. If you are
more interested to work on resolver refactoring, I certainly have
nothing against it. I do believe it is important all Tycho developers
should have common understanding of project goals and priorities at
least at high level. This is why I ask for all non-trivial work to be
"announced" on tycho-dev and all major changes be agreed upon before
anything gets pushed to master.
--
Regards,
Igor
