Bugzilla – Full Text Bug Listing
| Summary: | Support dependency management through .target files | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Tobias Oberlies <t-oberlies> | ||||||
| Component: | Tycho | Assignee: | Tobias Oberlies <t-oberlies> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | major | ||||||||
| Priority: | P2 | CC: | eric.jain, hendrik, igor, jan.sievers, jingweno, kai, manderse, mn, sebastien.arod, steffen.kriese, steffen.pingel, tokraemercli, vrentschler | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 342704 | ||||||||
| Attachments: |
|
||||||||
I also see .target files as the only reasonable way to include negative requirements (see Jan's comment 8 in bug 342704) because you really need a UI for this. The target editor can show the content of a target definition today, so it would allow to verify that the unwanted dependencies are in fact removed when adding negative requirements without having to run a product build. If we should make negative requirements more convenient to use (just in case...), we should do this through support in .target files. interpreting .target files same as PDE should also fix missing support for slicer mode in tycho , see https://issues.sonatype.org/browse/TYCHO-477 The missing support for slicer mode causes problems for multiple projects (Riena, RAP; see [1]). Therefore I think we should re-classify this as a major bug, possibly even as a blocker. [1] https://issues.sonatype.org/browse/TYCHO-477 I think several unrelated problems are mixed here. First, if Tycho indeed pulls org.eclipse.osgi bundle in the target platform of the attached project (sorry, can't try atm), this is clearly a bug and should be relatively easy to fix. During .target resolution, Tycho is not expected to consider dependencies of reactor projects, only their provided capabilities, so the attached project is expected to successfully resolve .target file but fail later on with "Import-Package: org.osgi.framework not found". Second, I agree we have a problem with optional dependencies. This problem is not limited to .target resolution but equally applies everywhere tycho resolves dependencies. I think we agreed during one of our eclipsecon "sessions" that there is no universally correct behaviour, some projects would expect/require such dependencies to be present while others will expect/require the opposite. I also think we agreed that Tycho will support two modes resolution modes with a pom.xml switch to choose between the two -- a) include all optional dependencies with ability to exclude unwanted ones and b) do not include any optional dependencies and let users explicitly manage them. Personally, I still believe mode b) will provide easier to understand and, more importantly, easier to maintain solution, but agreement is an agreement, so I am fine with having two modes ;-) Third, although I agree that compatibility with PDE is one of Tycho goals, I do not think we should blindly mimic PDE behaviour and ignore any possibility that cannot be mapped or easily implemented in PDE. I would like us to think about core Tycho functionality and PDE compatibility separately, with the latter implemented using the former. Igor, I would agree with you that Tycho should have its road map for the order of implementation. On the other hand, Tycho, as a Eclipse project, will run into bigger trouble if it doesn't even have full compatibility with PDE behavior and tries to do things differently. (In reply to comment #4) > I think several unrelated problems are mixed here. > > First, if Tycho indeed pulls org.eclipse.osgi bundle in the target platform of > the attached project (sorry, can't try atm), this is clearly a bug and should > be relatively easy to fix. During .target resolution, Tycho is not expected to > consider dependencies of reactor projects, only their provided capabilities, so > the attached project is expected to successfully resolve .target file but fail > later on with "Import-Package: org.osgi.framework not found". > > Second, I agree we have a problem with optional dependencies. This problem is > not limited to .target resolution but equally applies everywhere tycho resolves > dependencies. I think we agreed during one of our eclipsecon "sessions" that > there is no universally correct behaviour, some projects would expect/require > such dependencies to be present while others will expect/require the opposite. > I also think we agreed that Tycho will support two modes resolution modes with > a pom.xml switch to choose between the two -- a) include all optional > dependencies with ability to exclude unwanted ones and b) do not include any > optional dependencies and let users explicitly manage them. Personally, I still > believe mode b) will provide easier to understand and, more importantly, easier > to maintain solution, but agreement is an agreement, so I am fine with having > two modes ;-) > > Third, although I agree that compatibility with PDE is one of Tycho goals, I do > not think we should blindly mimic PDE behaviour and ignore any possibility that > cannot be mapped or easily implemented in PDE. I would like us to think about > core Tycho functionality and PDE compatibility separately, with the latter > implemented using the former. (In reply to comment #5) > Igor, I would agree with you that Tycho should have its road map for the order > of implementation. On the other hand, Tycho, as a Eclipse project, will run > into bigger trouble if it doesn't even have full compatibility with PDE > behavior and tries to do things differently. > tycho-dev@eclipse.org is more appropriate place to discuss this. (In reply to comment #4) > I think several unrelated problems are mixed here. You are correct: this bug describes several problems - problems which could be solved if we had PDE-equivalent support in Tycho. If you wanted to address the issues separately, you could certainly open individual bugs for the problems. Here, however, I would like to discuss/track the idea of implementing full target file support through re-using the PDE code. > Second, I agree we have a problem with optional dependencies. > ... mode b) will provide easier to understand and, more importantly, easier > to maintain solution... This is actually one of the strong points of target files: the editor has an analysis tab that lists the full content of the resolved target file. Therefore, the target file format is really where you want to implement tweaking options, like omitting optional dependencies, because there you can see the result immediately. But, again, this means that Tycho needs to re-use the target file interpretation logic. I am -0 on adding full .target file support in tycho, via PDE-reuse or otherwise. I believe resolving dependencies from local filesystem will cause problems in the long run, but I am too tired to argue against this. If other Tycho committers want to work on this I am not going to block it but I reserve the right to say "told ya!" when this does cause problems. I am strongly -1 no making .target file and "reused" PDE .target file interpretation logic the only/primary way to manage target platform configuration in Tycho. If this is your plan, lets discuss this on tycho-dev as I would like to hear input from wider community. (In reply to comment #3) > The missing support for slicer mode causes problems for multiple projects > (Riena, RAP; see [1]). Therefore I think we should re-classify this as a major > bug, possibly even as a blocker. > > [1] https://issues.sonatype.org/browse/TYCHO-477 We use Tycho to build a RAP application. To workaround the problem we use an empty feature with a p2.inf to indicates that the feature "provides" the "A.PDE.Target.Platform" capability. Then we create a .target file that reference the RAP runtime plus our fake feature accessible from a local site. I will attach the feature project. Created attachment 197696 [details] The Feature project described in comment 9 (In reply to comment #9) > To workaround the problem we use an empty feature with a p2.inf to indicates > that the feature "provides" the "A.PDE.Target.Platform" capability. > > Then we create a .target file that reference the RAP runtime plus our fake > feature accessible from a local site. How does this help? (In reply to comment #11) > (In reply to comment #9) > > To workaround the problem we use an empty feature with a p2.inf to indicates > > that the feature "provides" the "A.PDE.Target.Platform" capability. > > > > Then we create a .target file that reference the RAP runtime plus our fake > > feature accessible from a local site. > > How does this help? My post is a reply to https://issues.sonatype.org/browse/TYCHO-477 that describe the impossibility to use tycho to build a RAP application because of the p2 resolution mode. Since it's indicated that TYCHO-477 is now tracked here I also posted the comment here. I'm just sharing an ugly but simple workaround to this issue in the specific case of building with Tycho against the RAP target platform. Adding the fake IU "A.PDE.Target.Platform" satisfies the optional dependency declared by RAP to prevent installation in eclipse. I thought it could help other people building a RAP application with Tycho waiting for a real solution. (In reply to comment #12) > My post is a reply to https://issues.sonatype.org/browse/TYCHO-477 that describe > the impossibility to use tycho to build a RAP application because of the p2 > resolution mode. Since it's indicated that TYCHO-477 is now tracked here I also > posted the comment here. This makes sense. However I would prefer to still track the RAP issue in TYCHO-477 (or possibly a new alias for it here in bugzilla). IMHO TYCHO-477 is blocked by this issue, but not a duplicate of this issue. > I thought it could help other people building a RAP application with Tycho > waiting for a real solution. I guess it will. Thank you for sharing your workaround! (In reply to comment #8) > I am strongly -1 no making .target file and "reused" PDE .target file > interpretation logic the only/primary way to manage target platform > configuration in Tycho. If this is your plan, lets discuss this on tycho-dev as > I would like to hear input from wider community. Since we need this implemented quite urgently (since the fix for bug 348933, the units in target files are ignored altogther), we should probably just implement it in Tycho. For now, it should be sufficient to cover the main use cases: - type="InstallableUnit" with includeMode="Planner" (partially available in 0.12.0) - type="InstallableUnit" with includeMode="Slicer" (not available in 0.12.0) Phew! The first part is done: target files with only includeMode="Planner" (which is "Include required software" in the UI) should now be resolved correctly by Tycho :-) includeMode="Slicer" support will probably come next week. That's great to hear! Is it correct that this changes breaks builds that depend on includeMode="slicer" for now? Or do I need to specify something differently in my .target files now? Do I maybe need to specify the Environment now? (No need to do so up until now)... (In reply to comment #17) > Is it correct that this changes breaks builds that depend on > includeMode="slicer" for now? Or do I need to specify something differently in > my .target files now? Do I maybe need to specify the Environment now? (No need > to do so up until now)... It is quite likely that "slicer"-based target files don't work at the moment - sorry for that. You have the following options: - wait a few days - go back to the behaviour of last week, by disabling the target file in the target-platform-configuration and listing all repositories from the target file in the POM as repositories with layout p2. Note: this disables all dependency management. - go back to 0.12.0 Slicer mode is supported with commit 6aa2d242 :-D I would say that this fixes this issue. Other ideas (like supporting the other location types) should be proposed in new enhancement requests. And just for the record: I no longer believe that reusing the PDE code for resolving target platform is a good idea. The PDE classes/interfaces (e.g. IBundleContainer) only operate on bundles/features. They can't handle general IUs. This means that the PDE target resolution result is unsuitable for us, because certain operations (like building p2 repositories) require an IU-based target platform. Theoretically, we could move our TargetDefinitionResolver to p2 (and migrate the PDE code to use it), but I am not _that_ keen on code reuse ;-) |
Created attachment 193230 [details] Demonstrate that Tycho is not limited to .target content - the .target doesn't contain org.eclipse.osgi Currently Tycho doesn't have support for explicit dependency management: the dependency resolution cannot be forced to use only a subset of the content available in the listed repositories. (Note: Repositories listed in target files are treated in the same way as POM repositories with layout p2 - they are not restricted to the units in the resolved .target file; see attached demo project.) Tycho should interpret .target files in the same way as the PDE: it should restrict the content that can be seen from the build to the resolution result of the .target file. This would allow a strict dependency management through which certain problems that we see today can be prevented: - unwanted optional dependencies - use of newer versions of the project being built From an implementation point of view, this requires a two step depencency resolution: 1) Resolve the .target file(s) 2) Resolve the project dependencies (as today), using the resolution result of 1 as input For step 1, it should be possible to reuse the p2/PDE (?) implementation of .target file resolution. (If not, the p2/PDE code should be refactored so that this is possible.) Note that this enhancement does not affect users that just want to get started quickly: they could still use repositories with layout p2 in order to have Tycho to just download everything that is referenced in manifests, feature.xmls etc.