Community
Participate
Working Groups
In this case, it makes no since to "turn it on or off" (that belongs on the preference page itself). I think you just want to make sure some preference gets read and set in VM and there's no logical trigger for it (is there really no other trigger for it? A view opening? an Action performed? If it really *must* be done at start-up, when we move to manifest files, there's more power/control over what can execute vs. shat gets started, I think, something like Eclipse-AutoStart: true; exceptions="<packageClassname>.donotactivate"
David, I agree with the moral code behind this bug, but would prefer not to spend any time on it for a few reasons... 1. URL connections are initiated from a number of spots in the Web services code via the majority of the user actions which - as we continue plodding forward - will not be confined to the GUI (ie. headless scenarios would need to check for and load the preferences at most once prior to each snippet code that opens connections - further complicated by the fact that URL connections are sometimes driven by bundles of code beyond our reach, like the Axis emitters). 2. The startup code is extremely fast, and the plugin's dependencies are very light. I know the startup extension point is taboo, but I believe our use of it is as unintrusive as it gets. 3. Finally - We just need to get by until Eclipse v3.2, when all this stuff gets moved to the base, and the JRE properties can be loaded natively by org.eclipse.core.runtime or something.
I think you partially misunderstand ... if a user turns if off in startup preferences, they will unknowingly break the function you are intending to provide. "won't fix" is usually reserved for things that are a bad idea to change. If it get's to a matter of "there's no time", then please use "future". (And, please don't jump to that conclusion, without assigning to me :) it might be easier than you think :)
David, I understand the gotcha with startup. Users who disable the internet plugin at startup may impair firewall support. This may not ideal, but I suspect - perhaps wrongly - that most users don't disable startup of plugins unless they know what it is they are disabling. I believe the current implementation is quite sufficient to get us to Eclipse 3.2. My concern is not with the ease of a fix or that "there's no time" to make a fix. My concern is in expending any effort at all on providing a fix to a very low priority issue that will become obsolete in a few short months. I'll assign this to you for resolution as you see fit. PS: Could you refresh my addled memory - How would I mark a bug "Future"? Thanks - CB.
Ok, I've learned my great scheme won't currently work as I conceived of it, and have opened bug 100491 as feature request to see if possible in the future. I'm changing this to an "enhancement request" based on this new knowledge.
This RFE against WTP is obsolete now that the internet management plugin has been migrated to the platform via RFE bug 154100. Thanks - CB.
Closing as part of mass query to clean up old resolved bugs in untargetted milestones.
