[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tycho-dev] re, Deferring Dependency Resolution
|
On 11-11-14 1:52 PM, Oberlies, Tobias wrote:
-----Original Message-----
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.
I still need to have a closer look at the prototype, but, quite frankly,
I do not like the idea of letting mojos freely manipulate project
dependencies. This is simply not how maven works, so at very least this
behaviour will be "surprising" to anyone with Maven background.
On top of that, I still don't quite understand how you propose to let
mojos "filter metadata files on disk". Do you mean writing project
resolved target platform and dependencies as p2 content.xml and
artifact.xml files on disk and letting mojos "massage" those files? This
sounds like a really bad idea to me.
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.
I don't understand the usecase then. Can you give an example why mojo
would need to resolve project dependencies directly and what is
currently missing from existing APIs provided by Tycho to support this
usecase?
--
Regards,
Igor
