Community
Participate
Working Groups
Currently tycho only support P2-locations, but there are others as well (directory, Profile, feature). A first step to support these is parsing of the location types so they can be used in the resolving process, currently the are all handled as "OtherLocation" types and can't be used for further processing.
GitHub Pull Request 12 created by [laeubi] https://github.com/eclipse/tycho/pull/12
thanks. Please contribute to Tycho using Gerrit as described in https://wiki.eclipse.org/Tycho/Contributor_Guide
New Gerrit change created: https://git.eclipse.org/r/127871
Your proposal seems to be harmless and a good candidate for being merged but parsing it wouldn't make it used by Tycho dependnecy resolution. Can you please elaborate why you need it parsed? (just to evaluate whether there are some alternative to consider).
I'd like to try to add support for these types in the target resolving, to keep things small I thought it was a good idea to first add support for parsing those.
Ok.
Gerrit change https://git.eclipse.org/r/127871 was merged to [master]. Commit: http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=5fc933f651e344c0f1a1cebdc0e54fc8810cbb22
I merged your patch thanks. I can suggest that you retitle this bug with the final goal and we keep it open to track the whole story. We can keep working on finer grained patches/reviews if you prefer.
Ok, I'll take a look what might be a next step on the way :-) Thanks for reviewing/merging.
I have investigated a little bit whats going on under the hood and think there are two ways to archive this: 1) I can emulate an IInstallableUnit (this seems the way how maven artifacts are provided when using considerPomDependecies), but this is already marked as "fix it sometimes later" 2) I think currently the target definition concept of Tycho is different from the one in eclipse, Tycho completely relies on P2 metadata, but in eclipse a target platform is more a set of bundles and features, where P2 is just one source of bundles and features (for example you can't resolve P2 dependencies against Directory or Feature Locations). That is also why tycho currently can't support the "selected bundles" feature of the target platform. So I first need to introduce a concept of "TargetBundle/TargetFeature" that allows Tycho to resolve against instead of using P2 directly and push the P2 part away from the core resolving. Any thoughts?
(In reply to Christoph Läubrich from comment #10) > 1) I can emulate an IInstallableUnit (this seems the way how maven artifacts > are provided when using considerPomDependecies), but this is already marked > as "fix it sometimes later" Sounds like a good thing to do, especially if this was marked as a todo. It means the change is welcome. > 2) I think currently the target definition concept of Tycho is different > from the one in eclipse, Tycho completely relies on P2 metadata, but in > eclipse a target platform is more a set of bundles and features, where P2 is > just one source of bundles and features (for example you can't resolve P2 > dependencies against Directory or Feature Locations). Right. > That is also why tycho > currently can't support the "selected bundles" feature of the target > platform. > So I first need to introduce a concept of "TargetBundle/TargetFeature" that > allows Tycho to resolve against instead of using P2 directly and push the P2 > part away from the core resolving. This would be a difficult task. Tycho entirely relies on p2 for dependency management. Adding support for directory and non-p2 installation types would require to hook additional dependency resolution mechanism in Tycho, or to generate dummy p2 metadata for those units, to include during dependency management. As this is a big and difficult task in any case, I think it's better for you to first consider whether the ROI is there. About the "Installation" type, it's possible to interpret it as a p2-friendly source. The installation contains p2 metadata of the installed bundles. While this is not how PDE uses it, it could be a good way to implement it in Tycho without too much difficulty. If this is enough for your use-case, I'd suggest following this path which seems simpler to implement and powerful enough.
New Gerrit change created: https://git.eclipse.org/r/165135
Another consideration (In reply to Christoph Laeubrich from comment #10) > 1) I can emulate an IInstallableUnit (this seems the way how maven artifacts > are provided when using considerPomDependecies), but this is already marked > as "fix it sometimes later" As a consideration, this is also what we did in Fedora (OS) so that Tycho could resolve local artifacts. The build system there didn't allow contacting remote location (eg. a remote p2 repo) and all bundles were installed locally on the system. We basically created a p2 repository implementation that understood local filesystem locations ( https://fedoraproject.org/wiki/Tycho#Local_OSGi_bundle_resolution ). The work is at https://github.com/rgrunber/fedoraproject-p2 . It wasn't too difficult to get that working for directories. For additional locations you'd just need to implement IMetadataRepository, IArtifactRepository, and create your own subclasses of MetadataRepositoryFactory/ArtifactRepositoryFactory to have a way of recognizing when to act.
Gerrit change https://git.eclipse.org/r/c/tycho/org.eclipse.tycho/+/165135 was merged to [master]. Commit: http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=8a3fe3e4ae4df56462ea4967a7dbc775d682c593
Thanks a lot for this major addition Christoph! Can you please add a note about it to https://wiki.eclipse.org/Tycho/Release_Notes/2.0#New_and_Noteworthy ? Also, if you feel like you want to announce it on the tychp-user and/or tycho-dev mailing-list for feedback.
Added a note to the release-notes. I think user-list is a good idea so people can test as soon as possible as I'm sure there might be some cases that are not currently covered :-)
