Bugzilla – Full Text Bug Listing
| Summary: | [fwkAdmin] Remove program argument need to specify a number of arguments | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Pascal Rapicault <pascal> | ||||
| Component: | p2 | Assignee: | Simon Kaegi <simon_kaegi> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | aniefer, dj.houghton, Michael.Valenta, nalinig, pradeepb, simon_kaegi | ||||
| Version: | 3.5 | ||||||
| Target Milestone: | 3.5 M5 | ||||||
| Hardware: | PC | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Pascal Rapicault
Upon investigation, this occurs due to the way that the update and reconciliation happen. - We start with a 3.4.1 install which contains an eclipse.ini with references to the R34x launcher JARs. - Then we manually overwrite the eclipse.ini with one for 3.5 which contains references to the 3.5 launcher JAR - We start and try to reconcile - We attempt to unconfigure the old launcher JAR - This includes a call to #removeProgramArg - We remove "-startup" from the eclipse.ini - We then resolve the @artifact parm to be the R34x launcher JAR - We try to remove it from the ini file but since it has already been replaced with the new JAR, we don't find a match so the bogus entry is left in the file Pascal and I talked about this and the approach seems problematic. We both agree that a better approach would be for the #remove call to consume X number of arguments, rather than basing the removal on specific string matching. (e.g. "remove the -startup arg and the arg which follows it") Some arguments expect a following parameter and others don't. Some have optional parameters. I think the best that we can do to know how many arguments to remove is check if the next one starts with '-'. This problem with the wrong value of the argument occurs because the eclipse.ini file is replaced before the reconciler runs and contains values that confuse fwkAdmin. If the eclipse.ini is *not* replaced, then everything is fine. I'm now renaming the bug to focus on making the remove operation more robust to take a number of argument as described by DJ in comment #1. >Some arguments expect a following parameter and others don't. Some have optional parameters.
However in the touchpoint action we know how many entries are being added and as such we should be able to provide the right call to remove.
Created attachment 117317 [details]
patch
Pascal and I talked about this and we decided that the "consume all args until the next one that starts with a dash" approach is best. Here is a patch which implements this.
I don't think that we can use this same approach for the VM args though... I think there might be more non-dash-prefixed args and we might get into trouble. Thoughts?
One scenario that Pascal and I were worried about was when you have multiple args/values on the command-line with the same value. Consider the following command-line:
-launcher foo.jar -debug -startup foo.jar
Because the way the string scanning and matching is done, with the old code (using the old metadata which will have 2 calls to #removeProgramArg, one for "-startup" and one for "foo.jar"), the resulting command-line would be:
-launcher -debug foo.jar
With the new code (again with the old metadata) the result would be:
-launcher -debug
Note that this patch does not include any metadata generator/publisher changes which would remove the second call to #removeProgramArg from generated metadata. Once the metadata is generated such that it only has one call to remove the arg, then the result will be fine.
*** Bug 257775 has been marked as a duplicate of this bug. *** Fixed in HEAD. I tweaked your(DJ's) code so that we would only remove arguments that were "-" prefixed in order to handle the -foo1 bar -foo2 bar case and tweaked your test accordingly. I also had to adjust the undo logic for the Add/RemoveProgramArgument actions and tests however they all pass sucessfully now. |