TargetDefinitionGenerator generates target platform with extraneous dependencies [message #1849374] |
Fri, 14 January 2022 15:46 |
Florent Latombe Messages: 8 Registered: December 2014 |
Junior Member |
|
|
Hi
I have created a projects catalog providing several different projects.
A targlet task in the projects catalog setup allows sharing one list of p2 repositories that is used by all the projects it provides.
Each project specifies a targlet task with a source locator pointing to its cloned Git repository, resulting in the provisioning of the workspace and modular target platform.
With the http:/www.eclipse.org/oomph/targlets/TargetDefinitionGenerator annotation, the corresponding .target file is generated for the Tycho build of each project.
This works fine when during the installation I only select one project: its targlet finds the dependencies from the p2 repositories, imports the projects from the Git repository into the workspace, and generates the corresponding .target file.
My issue is that if I select several projects, then the workspace provisioning is fine but the targlet resolution behavior (and thus, .target file generation) depends on the order I selected my projects in the installer wizard: the targlets are "cumulatively" resolved, meaning the dependencies of the former projects end up also being present in the dependencies of the latter projects.
For instance, if I have projects A and B with B having "additional dependencies" compared to A:
* If in the installer wizard I select A then B, then the targlet of A is resolved and generated as .target, which is fine,
then the targlet of B is resolved and generated as .target, which is fine also.
NB: in that case, B's targlet is used as target platform as it is the latest that is handled by the setup tasks
* If in the installer wizard I select B then A, then the targlet of B is resolved and generated as .target, which is fine,
then the targlet of A is resolved and generated as .target, but it contains the "additional" dependencies of B
NB: and in that case, A's targlet is used as target platform.
This does not hinder the successful compilation of A, but it means there are "too much" dependencies in the .target of A, which are actually of no use for that project. Also because the contents of the .target for project A depends on the installation (e.g. whether I selected only A, A then B, or B then A), then my .target file which is versioned shows significant changes.
What is most surprising to me is how Oomph composes targlets ; I would have expected it to create a "synthetic" modular target to capture the contents of all individual targlets, i.e. something like "targlet1+targlet2", instead of accumulating the contents of "targlet1" into "targlet2" (resulting in there being "targlet1" and "targlet1+2"). Or, at least, that the generated .target file could filter out the irrelevant dependencies from its contents.
Is there maybe a way to structure my setup such that each project could have its own non-cumulative targlet, and also that I could have one setup-wide targlet in which the targlet composition would happen ?
Thanks for you help,
Florent
|
|
|
|
Re: TargetDefinitionGenerator generates target platform with extraneous dependencies [message #1849658 is a reply to message #1849382] |
Fri, 28 January 2022 08:30 |
Florent Latombe Messages: 8 Registered: December 2014 |
Junior Member |
|
|
Thanks for your answer Ed, that is indeed what I observed and understood.
In the case of a workspace with several projects for which we want to generate the .target file, this makes the generated files pretty innacurate because they will have a lot of extraneous dependencies. But I understand that the fix would require a significant rework of the way combined targlets are resolved.
In case anyone hits the same issue, the workaround is to setup a workspace with just the one project you want to update the target platform file for.
[Updated on: Fri, 28 January 2022 08:30] Report message to a moderator
|
|
|
Powered by
FUDForum. Page generated in 0.02812 seconds