- This topic has 4 replies, 2 voices, and was last updated 19 years, 9 months ago by
.
-
Posts
-
Greetings:
The “latest” version of MyEclipse has a couple of annoying behaviors:
1: Incorrect Versioning. Despite repeated attempts to get MyEclipse Version 8 Beta, the MyEclipse “about” window shows all plugins as being Version 2.7.101. Is there something wrong with your downloads page? Or is it that the folks ofering 3.8 beta didn’t bother updating the version listed by the plugins? Either way, this seriously needs fixing.
2: Scanning for updates in the so- called Version 3.8 Beta causes a warning box to appear that says the following:
“The current configuration contains errors and this operation can have unpredictable results. Do you want to continue?”
You can click on “OK”, but it is uncertain that a real update scan is being done.
3: Extremely annoying loss of subscription info! This occurs whenever you open a new workspace. If you stay in an existing workspace there seems to be no problem (so far). But if you create a new workspace, use of any MyEclipse features causes that warning dialog to appear saying that you have less than 30 days to upgrade your subscription. The only way to avoid this annoyance is to re- enter your subscription information (or to only use one workspace forever!)…
These problems are in serious need of fixing. Who do I contact about these problems and how long will it be before such problems are addressed?
Factor3
1: Incorrect Versioning.
The beta versioning is correct. Please note that there are both 2.8 and 3.8 beta versions as they correspond to the appropriate Eclipse version number. There is no Eclipse standard for labeling beta or milestone releases. Since version 3.8 Final will be labeled as version 3.8.0, we want to reserve that numeric id. So, while working on Betas we label them in the 100’s of the previous minor build so that they are numerically lower than the final build number will be in order for the update manager to recognize them properly. For example, 3.8 Beta 1 was 3.7.100 and 3.8 Beta 2 was 3.7.200. To find the descriptive version, navigate to Window > Preferences > MyEclipse and look at the installation description.
2: Scanning for updates in the so- called Version 3.8 Beta causes a warning box to appear that says the following:
“The current configuration contains errors and this operation can have unpredictable results. Do you want to continue?”
You can click on “OK”, but it is uncertain that a real update scan is being done.I can’t find any problem with the MyEclipse 3.8 update site. It simply shows no updates available. However, if you scanned earlier you might’ve caught the interval when we were updating the site or turning it off as described in this link: http://www.myeclipseide.com/PNphpBB2+file-viewtopic-t-2915.html
Please note that the problem described in the URL is caused because the Eclipse team does not have a versioning scheme for milestone builds, thus confusing their update manager, which is why we label ours explicitly as described in point 1.3: Extremely annoying loss of subscription info! This occurs whenever you open a new workspace.
Yes, that’s because it’s stored as a preference and you lose it just like *all* your preference settings because Eclipse does not provide any global mechanisms for maintaining state across workbenches. That’s why you also have to go reinput all your preference settings when you create a new workspace. The subscription key is just one such setting. To make this easier, however, Eclipse does provide a preference export/import mechansim that will duplicate all your preferences, subscription key included. You can get to it at Window > Preferences > Export… at the bottom of the window.
There is no Eclipse standard for labeling beta or milestone releases. Since version 3.8 Final will be labeled as version 3.8.0, we want to reserve that numeric id. So, while working on Betas we label them in the 100’s of the previous minor build so that they are numerically lower than the final build number will be in order for the update manager to recognize them properly.
OK, no problem. I did not realize that the download manager had that inadequacy. This is good to know.
I can’t find any problem with the MyEclipse 3.8 update site. It simply shows no updates available. However, if you scanned earlier you might’ve caught the interval when we were updating the site or turning it off as described in this link: http://www.myeclipseide.com/PNphpBB2+file-viewtopic-t-2915.html
Please note that the problem described in the URL is caused because the Eclipse team does not have a versioning scheme for milestone builds, thus confusing their update manager, which is why we label ours explicitly as described in point 1.Please reread my previous post. I didn’t say anything about a problem in the update site; this topic is about “annoying behaviors in 3.8 beta”.
FYI, I did some checking. It turns out that the error showing up when I check for updates has to do with a missing plugin. Apparently, I can check the reason for an error when it appears in the update manager (an “Error Details” button appears when the error does). When I display the “error details” I get the following:
The current configuration contains errors and this operation can have unpredictable results.
MyEclipse Core Tooling (3.7.101) requires plug-in “org.apache.xerces”.This would indicate that something is missing in the MyEclipse download, or that the “Core Tooling” part of MyEclipse is failing to find an existing plugin. Either way, it is, as I’ve said, an annoying behavior in 3.8 Beta — not an update site problem.
By the way: despite this error, I was able to download new software using the update systems on other sites, so fortunately the configuration problem is not (so far) effecting the ability to actually update.
Yes, that’s because it’s stored as a preference and you lose it just like *all* your preference settings because Eclipse does not provide any global mechanisms for maintaining state across workbenches.
Yes, I am aware of this inadequacy in Eclipse, and I know that that is why every time I change my workbench Eclipse loses my subscription information.
But there are other places where such information can be stored, where info won’t be lost from Workbench to Workbench. Furthermore, this topic is, after all, a description of “annoying behaviors” in 3.8 Beta — and the loss of subscription information — even if it is easily recoverable — *is* an annoying behavior.
Consider this complaint a “gentle, subtle” hint: that maybe it would be better to put subscription information somewhere *other* than in the Preferences section???
Just a thought…
Factor Three
Factor,
The current configuration contains errors and this operation can have unpredictable results.
MyEclipse Core Tooling (3.7.101) requires plug-in “org.apache.xerces”.
This would indicate that something is missing in the MyEclipse download, or that the “Core Tooling” part of MyEclipse is failing to find an existing plugin. Either way, it is, as I’ve said, an annoying behavior in 3.8 Beta — not an update site problem.Actually, that was a known problem in 3.8 Beta 1 that was addressed as part of Beta 2.
But there are other places where such information can be stored, where info won’t be lost from Workbench to Workbench.
Consider this complaint a “gentle, subtle” hint: that maybe it would be better to put subscription information somewhere *other* than in the Preferences section???Can you enumerate what these might be, remembering that we ship on three different platforms? Perhaps I can log an enhancement request, but I’ll need to have a specific recommendation. 🙂
Can you enumerate what these might be, remembering that we ship on three different platforms? Perhaps I can log an enhancement request, but I’ll need to have a specific recommendation.
Actually, the file (or files) contaning such information could be placed pretty much anywhere within the directory where the MyEclipse Plugins reside. They don’t even have to be in with the plugins; you can place them just about anywhere under the MyEclipse installation directory.
They can be put in any format and can (using JSSE or some other API) even be encrypted if you wanted them to be. The subscription information can be in XML format or (more simply) in a .properties file. The plugin (or part of a plugin) that handles subscriptions could then “know”, based on the installation directory, where to get the subscription information, and if the file doesn’t exist or if it does not contain a valid key the subscription system would act as it should when someone hasn’t subscribed.
This could be implemented using regular Java Stream classes, or if you are into NIO, you can use that. If you used a properties file, things would be simpler; just use the Properties class to get and check the subscription info. Just decide what subdirectory under MyEclipse you want to use and instruct all plugins that use that information to look into a specific file in that directory, or (better) have a class load subscription information from that specific file when MyEclipse plugins are initialized.
In other words, this is not rocket science. Putting in such a mechanism wouldn’t take a lot of work (assuming, of course, that you folks implemented the MyEclipse plugins as true components), and will have the incalculable value of having gotten rid of a really annoying behavior in your product.
-Factor Three
