Community
Participate
Working Groups
Hi Setting target platform does not execute configure phase and we could not find a way to plug and execute the configure phase. The scenario that we want to work is to get all start level values that are specified in touchpoints in a certain target platform. So we can have correct start levels for the bundles. Scenario to reproduce is if you have the p2 dropins bundle (org.eclipse.equinox.p2.reconciler.dropins ) and it is started before the p2.repository bundle (since in the launch configuration they have one and the same start level) NPE occurs.
Created attachment 199243 [details] added configuration phase.
Jeff, can you comment on this? I believe there was a reason we chose to exclude the configure phase when provisioning.
Hi, Another solution could be to make it configurable and the default behavior to remain as it was if there is a good reason behind not having configure phase.
I think the issue is finding a location where the configuration should go. The start levels are useful in launch configurations. However, launch configurations have a completely different life-cycle than target platforms. They can be created, copied, modified an removed freely while the target platform remains unchanged.
Gunnar I think there is already such location. Installing phase needs to store configuration information as well (although it is much less). I have tested on our project and it works fine. It finds the config.ini file and edits it accordingly. In case of simple configurator is used it works as well. If you do not want to make this default behavior then we can do it optional and up to the adopter to configure.
(In reply to comment #5) > I have tested on our project and it works fine. It finds the config.ini file > and edits it accordingly. Which config.ini file do you use in your case?
The one which is under property: ${org.eclipse.equinox.p2.installFolder}\configuration in the case of simple configurator: ${org.eclipse.equinox.p2.installFolder}\configuration\org.eclipse.equinox.simpleconfigurator\bundles.info And this is fine for us.
Dimitar, I'm worried about the actual location of "${org.eclipse.equinox.p2.installFolder}". For example, on my local system this seems to be: <workspace>/.metadata/.plugins/org.eclipse.pde.core/.install_folders/<some-random-number> I think that the configuration data is not helpful at this location. Instead I think it should be applied to: <workspace>/.metadata/.plugins/org.eclipse.pde.core/<configuration-area> However, the latter is launch configuration specific and there may be many launch configurations. It would be nice if the information could somehow be applied from the install folder to the actual launch configuration itself. Otherwise it won't be useful to Eclipse PDE users.
Definitely it should be read by the launch configurations at the end this is our goal:) For short term solution this location is ok for us. And if adding the configure phase does not bring any harm then we could enable it (or making it configurable so we can enable it in our adopter product). And we can configure the launch configuration on our side reading the information from the generated files. And for juno or post-juno we should go with the approach you have described.
Right, the patch is small and does not do any harm. Can you open a new request for the enhancements to the launching? Having it in Juno would be great. We just need someone to contribute it. :)
ok bug created: https://bugs.eclipse.org/bugs/show_bug.cgi?id=354233 As for the contribution. Some of the features we will create in our product and it makes much more sense to place them in PDE, so it should not be a problem.
(In reply to comment #10) > Right, the patch is small and does not do any harm. We can have it for 3.7.1 then?
Gunnar is it possible to have this in a maintenance release? We can work for the complete solution (bug: 354233) for 3.8.
Sorry, that's not my decision. I'm not a PDE committer.
Curtis, or some from the PDE commiters group, could some of you kindly check the options to have this in a maintenance release? Thanks in advance
We will consider this for 3.7.2, but I haven't found time to review this change.
One thing to keep in mind is that the target platform is not guaranteed to be interesting/useful/runnable. For example, there may be multiple mutually conflicting bundles present in the target (e.g., multiple platforms). The launch configuration is the logical equivalent of the standard p2 profile. So the proposed change is an interesting way of seeding launch configurations based on the target and the approach will apply in a number of scenarios. It is not however universally the way things should work IMHO. I'm for supporting the idea but do worry about the workflow and confuse for the user. This will be very hard to explain to people and set expectations correctly. In general I have tried to even stay away from the term "install" when talking about targets. From a user point of view we are really just "fetching" the stuff.
Hi Jeff, you are absolutely right, "target platform is not guaranteed to be interesting/useful/runnable" and we will have to deal with this. Currently (at least from my perspective) this is the right way we can transfer the information to the launch configuration. We have developed some really ugly workarounds for this, and we really want to remove them:) thanks, Dimitar
If possible having the change in an early milestone will be great for us. Thanks, Dimitar
I meant maintenance not milestone sorry about that.
With the configuration phase added I am still able to use update sites in my targets with no issues. I think we should put this in to 3.8 M4 and continue to evaluate it before considering backporting it. (In reply to comment #17) > I'm for supporting the idea but do worry about the workflow and confuse for the > user. This will be very hard to explain to people and set expectations > correctly. In general I have tried to even stay away from the term "install" > when talking about targets. From a user point of view we are really just > "fetching" the stuff. I do not see how this causes a workflow change or confusion for the user, but I am concerned there are consequences I am not seeing. Does adding the configure phase increase the likelihood of the provision (plan or slice) failing? cc'ing John and DJ as they have more in-depth knowledge of p2 and may be able to provide some insight.
I've changed this in the master branch so we can try it in nightly builds. http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=98b0e5001ee289abba2343395bb3446cc664bdbf
So far no problems have been reported. Marking as FIXED.
Hi Curtis, (In reply to comment #21) > With the configuration phase added I am still able to use update sites in my > targets with no issues. I think we should put this in to 3.8 M4 and continue > to evaluate it before considering backporting it. Do you think we can have the fix for SR2? best regards, Dimitar
(In reply to comment #24) > Hi Curtis, > > (In reply to comment #21) > > With the configuration phase added I am still able to use update sites in my > > targets with no issues. I think we should put this in to 3.8 M4 and continue > > to evaluate it before considering backporting it. > > Do you think we can have the fix for SR2? > > best regards, > Dimitar This is really difficult to justify backporting. It's new functionality, not a fix for a regression. While it hasn't caused any problems yet, no p2 experts are coming forward to say that a change like this is safe/low-risk. PDE needs to be very careful with its 3.7.2 fixes as we will not have the resources to do a complete smoke test during the end game.
> This is really difficult to justify backporting. It's new functionality, not a > fix for a regression. While it hasn't caused any problems yet, no p2 experts > are coming forward to say that a change like this is safe/low-risk. -1 to backport this as is but we could backport it with a switch based on a system property to enable the new behavior.
Sorry for not responding earlier. Having it in juno is ok with us. Indigo would be better, but you are right it is risky to have it on this stage (SR2). You can close the bug.
Hello, I would like to reopen this bug please, since it is breaking existing (before the change) functionality. --------- Problem --------- Since the configure phase has been added, the target platform resolver blocks on features that need custom p2 touchpoint actions, because it is unable to get them even if their repo is part of the target. -------- Details -------- Native touchpoint actions such as rm() ,copy() or Eclipse touchpoint actions such as setStartLevel() are defined in p2 plugins part of every eclipse ide installations. At my company, we have create custom touchpoint actions, to support migrations of plugins inside our products; those custom touchpoint actions are hosted on a p2 repo. Then we have our plugins, that define, at the configure phase, use of some of those touchpoint actions. When we build our products with those plugins, those custom touchpoint actions will be downloaded from their repo, thanks to p2 meta requirements that can enrich the builder, and then will get executed at configure phase of the installation of the plugins. ------------------------- How to reproduce the bug ------------------------- Inside Eclipse 3.8m4+ , import this target platform : https://github.com/anthonydahanne/tycho-Bug-351487/blob/master/com.compuware.touchpoint.target/touchpoint.target The TP editor will hang telling that "No Action found for com.compuware.touchpoint.touchpoint" while trying to get the consumer feature. The problem can be reproduced also using the AntRunner and this ant task : <pde.provisionTargetDefinition targetFile="touchpoint.target" destinationDirectory="C:/eclipse" clearDestination="true"/> (you'll get java.lang.OutOfMemoryError: Java heap space issue) --------------------- Suggested solutions --------------------- Whether * we revert the change (adding configure phase to the tp), or * we provide an option not do trigger this phase everytime, or * we complete the work including the p2 phase that resolves metarequirements and fetches the needed components inside the IDE ----------------- Workaround found ----------------- If you install inside your IDE the feature providing the missing touchpoint actions ( with the example provided, install com.compuware.touchpoint.feature from http://anthonydahanne.github.com/tycho-Bug-351487/ repo) the tp resolver does not complain anymore since it is aware of the custom touchpoint actions Please tell me which suggested solution is the most acceptable and I will start working on the fix
Curtis, please take a look.
(In reply to comment #28) > --------------------- > Suggested solutions > --------------------- > Whether > * we revert the change (adding configure phase to the tp), or > * we provide an option not do trigger this phase everytime, or > * we complete the work including the p2 phase that resolves metarequirements > and fetches the needed components inside the IDE > The difficulty in executing all custom touchpoints is that they may require additional repositories not included in the context. The local install is added to the context, which is why the workaround you discovered likely worked. If you have the time to investigate a solution to this, that would be great. The simpler solution would be to only perform the configure phase if a preference or property is set. The configure phase is only required in special circumstances, so it should not be the default behaviour.
(In reply to comment #30) > The difficulty in executing all custom touchpoints is that they may require > additional repositories not included in the context. The local install is > added to the context, which is why the workaround you discovered likely worked. > If you have the time to investigate a solution to this, that would be great. usually if the feature defining the custom touchpoints is included in the target, it is enough for p2 to find it and provision it; but not in this case... I'll try to look... > > The simpler solution would be to only perform the configure phase if a > preference or property is set. The configure phase is only required in special > circumstances, so it should not be the default behaviour. Agreed, something like a checkbox "Use the configure phase during provisioning" , default unchecked, in the Definition tab of the UI (and a similar param for the ant task if it is needed)
Fixed in master: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=81ae025bd7a6f8b253e7178e38af5f1f664a544b "Include configuration phase" setting added to the included software section of the edit software site location dialog. While testing this, I keep running into a problem with the synchronizer (bug 371944), so I will work on fixing that right away.
(In reply to comment #32) > Fixed in master: > http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=81ae025bd7a6f8b253e7178e38af5f1f664a544b > > "Include configuration phase" setting added to the included software section of > the edit software site location dialog. > > While testing this, I keep running into a problem with the synchronizer (bug > 371944), so I will work on fixing that right away. Curtis, thank you so much for providing this patch so rapidly; I really appreciate it. I had a look at the patch, now I'll try to experiment it with the next Milestone build including it. thanks again !!!
