[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [p2-dev] .target File - includeConfigurePhase, includeMode, ...
|
Gilles,
I fear the expertise to answer this is not available and it's hard to
find any documentation on these details.
No doubt you found this, but that tells you nothing about these details:
https://wiki.eclipse.org/PDE/Target_Definitions
This doesn't provide such detail either:
https://help.eclipse.org/2019-09/index.jsp?topic=/org.eclipse.pde.doc.user/concepts/target.htm
If I understand correctly how these function, the planner includeMode
will resolve all transitive dependencies and will fail if all
dependencies can't be resolved or if there are conflicts (i.e., multiple
singletons are required), while slicer model resolves as much as is
possible but doesn't fail if dependencies are missing (or if there are
multiple singletons).
I believe the includeConfigurePhase determines whether touchpoint logic
(touchpoints as specified in the artifact metadata) is applied to the
downloaded artifact; but I'm not sure about the exact details of which
touchpoints might not function properly. Generally I have this true
everywhere and it doesn't cause problems so I don't worry about it.
Touchpoints are extensible and there is a concept of meta-requirements
that can require the touchpoint processor's bundle to be installed in
order to be able to invoke the touchpoint logic and I suppose that could
be problematic such that you'd want to disable the touchpoints. It's
just my theory...
The includeAllPlatforms determines how fragments are resolved, i.e.,
just the ones for the current OS/WS/Arch or all available ones. When
building Oomph, we include fragments in our own features so we need all
fragments to be available to avoid warnings about missing references in
our feature.xmls. But of course at development time, we only need to
launch with the fragments appropriate for our current environment...
The includeSource determines whether the corresponding source
features/bundles will be resolved into the target platform. Generally
this is only important at development time where it's great to have
source code available for debugging purposes.
PDE is extensible and supports different types of locations. E.g., Oomph
uses this to contribute Targlets:
https://wiki.eclipse.org/Oomph_Targlets
It actually implements that shared bundle pool concept described here:
https://wiki.eclipse.org/PDE/Target_Definitions#Redownloading_of_Bundles
<rant>The Target Definition Editor in my opinion is a nightmare. I
don't understand why the editor insists on downloading all artifacts
just to edit the .target file. And in the end, it's painful and
embarrassing that each resolve spends so much time downloading the same
artifacts (typically yet again) and creates a gigantic copy of things
I've downloaded already in another workspace or that already exist in
the IDE itself. Why oh why is something so fundamentally important like
this?</rant>
End the end, I'm not sure that Tycho actually respects any of these
settings. It's not so clear which attributes are considered and
respected by Tycho looking at:
https://wiki.eclipse.org/Tycho/Target_Platform#Target_files
Certainly it's clear that it doesn't support many location types, so it
doesn't support Oomph Targlets directly. As such Oomph supports
generating a *.target file from the Targlet locations and we use that to
avoid ever editing a *.target file.
Because I want to know everything, I typically maintain a workspace with
"everything" in it:
https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning
Then I can always dive deep to see how things are implemented in
excruciating detail...
Regards,
Ed
On 30.10.2019 18:45, Gilles Iachelini wrote:
dear fellow readers,
I am currently working with target platform files and we are trying to strip down our dependencies of our RCP application, server components using osgi and many other projects using a target platform.
I am looking for explanations what actually happens when the keywords within the location tag of a .target file like
- includeConfigurePhase
- includeMode
- includeAllPlatforms
- includeSource
- type
are used. I know, that using includeMode=“slicer” helps to reference, for instance, language fragments, which by nature have a reference to a host bundle, which is not necessarily part of the target platform, but must be available at build/package time. Why does every location must use the “slicer” mode, when one location is using it?
We are using the target platform file in the maven/tycho context to build our applications. There is a self explanatory charm to those attributes, but I have a hard time finding the definitions. Those explanations in the Eclipse Help aren’t very helpful, because they leave out the details.
For example to the “configurePhase” it says:
"Include configure phase is an advanced option to control whether the configure phase of the download operation will be run. The configure phase allows downloaded software to run additional operations. If this causes problems for your software site, this option can be turned off.”
I absolutely don’t want to blame anyone, but “advanced option” and “turn it of( if this causes trouble” isn’t really what I was looking for. I won’t mind a reference to source code. What are these operations and who has it?
All kind of comments are highly appreciated and I promise to collect all these comments and end the mystery of those keywords.
kind regards
Gilles
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/p2-dev
