Community
Participate
Working Groups
As discussed on bug 345234 with Tobias, tycho would greatly benefit from a p2mirror application that supports the option "-withSources". This option is a port of bug 329162329162: whenever a bundle is mirrored, we would try to locate the source bundle for it and mirror it too. I have ported Jeff's code in bug 329162329162 to p2director so I will try to use that experience to add this support to p2mirror.
Makes sense to me!
Tobias, Pascal, if that is OK I am assigning this bug to myself.
Created attachment 195469 [details] support for the flag -withSources This is the minimum to add the -withSources support. In fact it does not use at all the type of code that was done for the PDE equivalent. There is one case where the -withSources flag is not going to be supported with this patch: if an ant task setups the slicing options to "resolve" true. In that case it will use the Planner and we need to port the code that was done for PDE. Let me know if I should do that.
Created attachment 195470 [details] Launch config to test -withSources This is the launch config I used to test the -withSources flag.
Created attachment 195472 [details] New patch with -withSources and -usePlanner I added a flag to force using the planner; "-usePlanner". In fact it all works as expected. I have also added the application "org.eclipse.equinox.p2.repository.mirrorApplication" that will mirror both the artifacts and the metadata. For those of us on the command line directly using the p2mirror. I think it would be a nice addition.
Despite being the guy who implemented the "with source" stuff for PDE etc I'm a little uneasy baking it into p2 itself. p2 is supposed to be largely generic. The notion of with source is at least currently very specific. This approach to the mirror app does not scale well. If we had a more generic notion of "source" that was actually encoded in the metadata it would be much better. Even the current implementation of the with source stuff in PDE is a hack that uses IU/bundle naming conventions. It could really benefit from the additional metadata. Just my 2c... BTW, if we do put this in, please make the "source" part singular. e.g., withSource as in "would you like source with that sir?"
I second Jeff's concerns. We shouldn't start porting this workaround to other tools, because we'll never get them all. (For example for Tycho, this patch would allow to deliver locally built source bundles, but you wouldn't be able to assemble source bundles from outside the reactor. This would require a patch in the Tycho dependency resolver...). We should solve this properly instead. A proper solution I could think of is a filtered dependency from the bundle IU to the source bundle IU. @Jeff: Has this already been discussed, or should I open a new enhancement request for that?
Things like this have been discussed since the beginning and perhaps more recently. AFAICT we have never come to a conclusion about it. The closest thing we have in p2 now is the feature JAR IU that is applicable only if the "install features" property is set on the profile. Not sure if exactly the same approach should be taken but you get the idea. I am not seeing a recent bug open about this though so a new enhancement request would be good.
Thanks for the review everyone. When we last discussed this type of additions to existing p2 application, I think we suggested that we would refactor some of the internal code to be able to extend them directly in java. I have followed this principle for the p2director app in the bug 345578 according to Jeff's message here: http://dev.eclipse.org/mhonarc/lists/p2-dev/msg03483.html Should I attach a new patch for the p2mirror application that enables us to extend it easily? I don't think the ability to extend those apps should be considered an API that must be maintained forever. However it would be good to keep somewhere some examples that take advantage of this so we know when we break it. Tobias, we could take advantage of this in tycho and keep the "-withSource" support in an extended p2mirror app developped at tycho this way. Once the support for source metadata is ready, tycho can them move on to use that.
The addition of markup to identify the source of an IU has been discussed in bug #220254 a couple years ago but we never got around to implement it. What we need is something simple like have an IU say "I'm a source for this other UI". The idea of a filter is not a good idea because then it is all or nothing.
(In reply to comment #10) > The addition of markup to identify the source of an IU has been discussed in bug > #220254 a couple years ago but we never got around to implement it. What we need > is something simple like have an IU say "I'm a source for this other UI". The > idea of a filter is not a good idea because then it is all or nothing. I do think that a filtered, optional dependency would be a good solution for many people. I filed a new enhancement request for this: bug 347483. I would appreciate your feedback, and in case it is positive I may even get around to implementing it myself :-)
I think we have an agreement that we won't be porting Jeff's "Would you like source with that?" magic into p2. The solution for this issue will either be based on bug 220254 or bug 347483. I changed the title from "[tools] p2 mirror enhancement: port of "with sources"" to "[tools] p2 mirror enhancement: include sources" capture the more generic requirement
Agreed, in the context of tycho this very small patch looked like the thing to do. In the scope of what p2 does and the fact that those applications like p2mirror should remain abstracted from eclipse it is not the right solution. There are other use-cases where being able to extend the p2 applications would be so much better than forking them. p2mirror 'withSource' is one case (If I can't wait for the final solution) and p2director is another case: (bug 345578). Would it be possible to mark some packages as x-internal and modify the code to use more protected fields and methods?
> Would it be possible to mark some packages as x-internal and modify the code to > use more protected fields and methods? This is definitely possible.
