Community
Participate
Working Groups
The TPD Plugin[1] has a convenient feature to include files, also tycho support defining multiple target files to be merged, this could be useful for plain pde targets as well: a) one might reuse some target from another source but extend it with additional stuff b) one might like to split a target into smaller more manageable chuncks c) one might to have some stuff resolved with planner but other with slicer mode The proposal is to add a new target-type 'target' with a single attribute 'uri' this uri could then point to the actual target to resolve and include in the resulting target. URI here means: any URI that could be converted into an URL (to open a stream) and the URI should be capable of containing placeholder like directory locations. I'll provide a gerrit for this in the next days ... [1] https://github.com/eclipse-cbi/targetplatform-dsl#syntax
A target file then might look like this: <target name="main"> <locations> <location type="target" uri="file:${project_loc:/target.refs}/other.target"/> <location type="target" uri="http://<somehost>/shared/rcp_base.target"/> ... some other locations ... </locations> </target>
(In reply to Christoph Laeubrich from comment #1) > A target file then might look like this: > > <location type="target" > uri="file:${project_loc:/target.refs}/other.target"/> Will it work from tycho cli build?
(In reply to Alexander Fedorov from comment #2) > (In reply to Christoph Laeubrich from comment #1) > > A target file then might look like this: > > > > <location type="target" > > uri="file:${project_loc:/target.refs}/other.target"/> > > Will it work from tycho cli build? When it is added to PDE we can add support for it in tycho as well.
(In reply to Christoph Laeubrich from comment #3) > (In reply to Alexander Fedorov from comment #2) > > (In reply to Christoph Laeubrich from comment #1) > > > A target file then might look like this: > > > > > > <location type="target" > > > uri="file:${project_loc:/target.refs}/other.target"/> > > > > Will it work from tycho cli build? > > When it is added to PDE we can add support for it in tycho as well. Do you mean that Tycho will be running in a context where _all_ the variables are resolvable? Sounds like a miracle.
(In reply to Alexander Fedorov from comment #4) > Sounds like a miracle. Miracles happen! https://www.youtube.com/watch?v=sxKyBoYFUz4 > Do you mean that Tycho will be running in a context where _all_ the > variables are resolvable? Even inside eclipse not _all_ variables are always resolvable, Tycho currently support the following eclipse variables during the build: - system_property - env_var - project_loc which should satisfy most common use-cases.
New Gerrit change created: https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/187603
This is a very useful suggestion for PDE and I want to support it. I want to add the following remarks: - Instead of variables you could consider to use platform:/resource URIs, then variables don't have to be considered (nevertheless platform-resourceURIs could be specially supported in the UI, e.g. by listing all projects in the workspace). Or are platform:/resource -URIs not supported by Tycho unlike 'project_loc' variables that you have mentioned. - It could be useful to be able to specify multiple uri's for the same target, where the first available URI is taken. My idea behind that is the following: Given that one wants refer to a .target file maintained in another git repo and published to a remote repo. At first one wants to refer to the .target file at the remote repo. But if later one imports the referenced target-file (respectively its container-project) from the git-repo into the workspace one usually wants to refer to the .target file in the workspace. This could be achieved when defining the target for example in the following way: <target name="main"> <locations> <location type="target"> <uri>file:${project_loc:/target.refs}/aTarget.target</uri> or <uri>platform:/resource/target.refs}/aTarget.target</uri> <uri>http://<somehost>/shared/aTarget.target"</uri> </location> </locations> </target> If the project 'target.refs' that contains 'aTarget.target' is available is is used, otherwise the remote target is used. The logic would to basically use the first URI in the list that is reachable. - Cycle-detection: Since the references to other targets form a directed-graph that is not guaranteed to be acyclic, a cycle detection should be added to prevent users from (accidentally) form cycles that would result in a not terminating target-resolution. The resolution could then fail or just emit a warning to raise awareness (not sure what is better). A cycle detection could be implemented by maintaining a Set of visited URIs. This would not guarantee to not visit the same target more than once because it could be reachable trough different URIs, but it would detect/break endless cycles because the target's references to other targets are definitively known already.
(In reply to Hannes Wellmann from comment #7) > This is a very useful suggestion for PDE and I want to support it. > > I want to add the following remarks: > > - Instead of variables you could consider to use platform:/resource URIs, > then variables don't have to be considered (nevertheless > platform-resourceURIs could be specially supported in the UI, e.g. by > listing all projects in the workspace). Or are platform:/resource -URIs not > supported by Tycho unlike 'project_loc' variables that you have mentioned. Actually any URL (including platform and even mvn ones) would be possible but one has to decide whether or not it makes sense to use them. I'm not aware of any support for platform:/ in tycho. > - It could be useful to be able to specify multiple uri's for the same > target, where the first available URI is taken. I don't think we should handle it that way as it will complicate things. Instead a more usefull feature would be to have a PDE feature that allows to specify mirror URLs in general (e.g. for regular UILoactions as well) as it is possible in tycho. But this would be a different story. > - Cycle-detection: > Since the references to other targets form a directed-graph that is not > guaranteed to be acyclic, a cycle detection should be added to prevent users > from (accidentally) form cycles that would result in a not terminating > target-resolution. This is not really possible in a consistent way due the way target resolution works. User should be responsible for taking care of this.
Created attachment 287512 [details] Current Test-Case I attach the test-case I'm currently using for development purpose, please fell free to enhance the test-project if you find any issues.
(In reply to Christoph Laeubrich from comment #8) > (In reply to Hannes Wellmann from comment #7) > > - It could be useful to be able to specify multiple uri's for the same > > target, where the first available URI is taken. > > I don't think we should handle it that way as it will complicate things. > Instead a more usefull feature would be to have a PDE feature that allows to > specify mirror URLs in general (e.g. for regular UILoactions as well) as it > is possible in tycho. But this would be a different story. That would indeed be also very handy for example to use company internal mirrors as alternatives to the regular repos to speed up artefact fetching and to reduce network-traffic. For my previously described scenario a project/target would have to declare that it is also published at a specific location. So it should be possible to specify such redirect on workspace and project level (so a simple preferences could be used?). Is there already a bug for such feature? > > > - Cycle-detection: > > Since the references to other targets form a directed-graph that is not > > guaranteed to be acyclic, a cycle detection should be added to prevent users > > from (accidentally) form cycles that would result in a not terminating > > target-resolution. > > This is not really possible in a consistent way due the way target > resolution works. User should be responsible for taking care of this. It would indeed not be possible directly. If it is considered as an important feature it could maybe achieved if the TargetDefinition class (and/or colleges) would be cooperative and would pass around the Set.
*** Bug 577005 has been marked as a duplicate of this bug. ***
Gerrit change https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/187603 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=71dc19e1679673d37fe4d4ada14f0bdd28ce71aa
Thanks, Christoph. Can you add this to the N&N for 4.23? Do we need another bug for Tycho to support this new construct?
(In reply to Lars Vogel from comment #13) > Thanks, Christoph. Can you add this to the N&N for 4.23? I'll try to find some time for this, if anyone is wiling to add it feel free to take over here ;-) > Do we need another bug for Tycho to support this new construct? See https://github.com/eclipse/tycho/issues/401
What's missing at the moment are some tests for the new functionality. Since I recently worked a lot with TP-tests I can contribute them as soon I have completed my other changes in PDE.
(In reply to Hannes Wellmann from comment #15) > What's missing at the moment are some tests for the new functionality. > Since I recently worked a lot with TP-tests I can contribute them as soon I > have completed my other changes in PDE. Thanks, Hannes.
This is now also supported in tycho see https://github.com/eclipse/tycho/blob/master/RELEASE_NOTES.md#support-for-nested-targets
I'm reopening as this topic still requires * N&N documentation * Inclusion in PDE doc (eg https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Fguide%2Ftools%2Ftarget_shared%2Fedit_target_wizard.htm )
See Bug 577184 which might have been caused by this change.
(In reply to Lars Vogel from comment #19) > See Bug 577184 which might have been caused by this change. Bug 577927.
(In reply to Mickael Istria from comment #18) > I'm reopening as this topic still requires > * N&N documentation > * Inclusion in PDE doc (eg > https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.pde.doc. > user%2Fguide%2Ftools%2Ftarget_shared%2Fedit_target_wizard.htm ) Christoph, can you please add these items?
Vikas thanks for the reminder. Actually I have no clue how to enhance the help is there a repository like for N&N?
(In reply to Christoph Laeubrich from comment #22) > Vikas thanks for the reminder. Actually I have no clue how to enhance the > help is there a repository like for N&N? Repo is https://git.eclipse.org/c/platform/eclipse.platform.common.git
In addition to the documentation request, I would like to say that the feature as currently described does not work well on Windows, because relative paths are not really usable and ${project_loc} expands to a path that is not URI-friendly. In particular, the example uses: <location type="Target" uri="file:${project_loc:/target.refs}/base.target"/> This works well in Linux, but in Windows it expands to a path like "file:C:\ws\prj\path/base.target" which results in an exception (invalid URI, illegal character in opaque part at index 7...) The same problem happens in the Tycho version of the nested target location support; I raised it in https://github.com/eclipse/tycho/issues/652 and the proposed solution was to simply convert Windows path separators to forward slashes when interpreting that field. That generates a URI like "file:C:/ws/prj/path/base.target" which works. Thus, I would ask for the same solution to be adopted in PDE so that target files remain compatible across both environments. PS: there is a more general problem with paths that have URI/URL-invalid characters (e.g. a path in Linux can legitimately include \ in a component) but that could be solved separately in the future, maybe by URL-encoding the expansion of project_loc.
Is N&N entry added for this?
(In reply to Vikas Chandra from comment #25) > Is N&N entry added for this? Nope I'm currently blocked by Bug 578697 (can't run Eclipse from the SDK anymore) and need to keep up with https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/24 because it seems git repositories where migrated in an unusual way...
Let's put in the N&N by RC1 at least.
(In reply to Javier Martin from comment #24) > Thus, I would ask for the same solution to be adopted in PDE so that target > files remain compatible across both environments. See https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/190949
New Gerrit change created: https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/190949
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/190951
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.common/+/190952
Gerrit change https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/190949 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=13fdea8ed9d7f8160fb1d3cc6f98baeac6a25bc0
Gerrit change https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/190951 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=42c8132e2ca7b4ea7076eea69e25eae3a2e9d136
I guess we are done here. Please test this feature and mark this as verified.
I confirm that the Windows-only issue is fixed in 4.23 I20220223-1800 and the referenced-target resolution works as expected. Thanks!
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.common/+/190952 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=5cd25095d800d4d22d0533ec7111411780a61384
