[Scott Anderson]

These are special instructions for using the MyEclipse update site to upgrade from MyEclipse 3.8.0 to 3.8.1. If you have a release of MyEclipse prior to 3.8.0 GA installed, please do not use the update site. Instead, use one of the downloadable platform-specific installers or the manual installation distribution. The update site is specifically built for upgrading only from 3.8.0 GA to 3.8.1.

The reason we’re providing a unique update site rather than using our default one is that we needed you to read and follow these specific instructions to work around a couple of bugs in the Eclipse platform update mechanism, specifically (Eclipse Bugs #70783/70176).
If you do not follow these instructions, you run a serious risk that the update will not be configured properly.

Here are the update steps:

First, you need to specify the update site manually by navigating to
Help > Software Updates… > “Search for new updates to install” > “New Remote Site…”
Enter a name you like (ie. MyEclipse 3.8.1 Update Site) with a URL of
http://www.myeclipseide.com/products/eworkbench/updates-3.8.0to3.8.1 and select “OK”
Check the new update site entry that is created and once Eclipse queries it and refreshes, select Next.
On the next wizard panel, select the line for MyEclipse 3.8.1 and select Next.
On the next wizard panel, select the terms of the license agreement and select Next.
On the final panel select Finish and then Install when you’re advised that the feature is not signed.

Once the installation completes, you’ll be presented with a dialog asking you if you want to restart.
Select *No*.
Once the dialog closes, immediately exit Eclipse.
In order to work around the Eclipse update bug referenced above, you now need to start Eclipse with the
-clean option. You can do this by modifying the alias you normally use to start Eclipse and passing it the commandline argument -clean. An example for a default Windows installation is shown below:

"C:\Program Files\eclipse-3.0\eclipse\eclipse.exe" -clean

When Eclipse restarts, MyEclipse 3.8.1 will be successfully installed. You can verify its presence by selecting Help > About Eclipse and then clicking on the MyEclipse icon to display the features installed.

If for some reason you let Eclipse restart itself rather than selecting “No” as instructed, simply exit the workbench, delete the log file at <workspace-location>/.metadata/.log and restart with
the -clean option to correct the installation.

We apologize for not being able to use our normal update site, but testing of it proved that these steps were needed in order to work around the Eclipse update bug and ensure a proper installation.

[Armen Yampolsky]

@support-scott wrote:

When Eclipse restarts, MyEclipse 3.8.1 will be successfully installed. You can verify its presence by selecting Help > About Eclipse and then clicking on the MyEclipse icon to display the features installed.

Yes, but the product no longer populates the “Provider” and “Plug-in Name” fields in any of the plug-in detail dialogs. An insignificant detail in what seems to be a super release. I think this is what many of us were expecting from 3.0 GA a week ago. Superb, and many many thanks!
-Armen

[Riyad Kalla]

Armen,
Are you seeing the blank boxes after using the -clean argument to start Eclipse? As I remember the side effect of NOT using “clean” was seeing a bunch of blank fields and having a lot of startup exceptions in the log file…

[Armen Yampolsky]

Riyad, I used the -clean arg when I restarted, and there are no exceptions in the logs. The version (3.8.1) and feature id (com.genuitec.xxx) fields are populated correctly, but “Provider” and “Plug-in Name” fields are blank. Like I said, pretty insignificant observation overall.

BTW, did the web project dependency bug get addressed in this release? I am still seeing the 3.8 GA issues with web projects:

(1) Classes in dependent projects are not visible.
(2) No rebuild occurs if java build path is modified.
(3) On manual clean/rebuild, package view only displays build errors in the first jsp page that (incorrectly) fails, all others appear as if they have no build problems.

[Riyad Kalla]

1) Make sure your deployment options are setup correctly, they might have rolled back to defaults. I just tried this locally and it worked fine for autocomplete as well as deployment but I did need to tell the deployer to JAR up dependant projects and stick it in the /lib dir.

2) This works for me (I took a web mod project and removed the J2EE Library Set and it recompiled with tons of errors)… do you mean compilation of your JSP pages or classes?

3) Interesting! I will file this ASAP, thank you.

[Armen Yampolsky]

@support-rkalla wrote:

1) Make sure your deployment options are setup correctly

This has nothing to do with deployment (BTW, yes deployment is set up correctly). What if I do not even set up a deployment? Can’t I work on a web app for a while without specifying the deployments? The deployment concern is a red herring and is not applicable to the problem I describe.

2) This works for me (I took a web mod project and removed the J2EE Library Set and it recompiled with tons of errors)… do you mean compilation of your JSP pages or classes?

I mean compilation of JSP pages, when you remove the workaround noted in the bug report: http://www.myeclipseide.com/PNphpBB2+file-viewtopic-t-3283.html

According to the workaround, one is required to add the classes from a project on which the web project depends to the build path in order for the web project to compile. However, if one removes this spurious classes entry, no automatic rebuild occurs and everything seems fine, which it is not. And if you now perform a manual clean/rebuild, only the first jsp page will show up as not having access to types in the dependent project, which is not consistent if other jsp pages reference those same types.

In other words, as far as I can tell, we still need the workaround from the GA release.

Other minor bugs in this release: There seem to be % symbols all over the Internet Tools preferences, as well as Workbench->Colors and Fonts->Structured Text Editor.name.

[Riyad Kalla]

This has nothing to do with deployment (BTW, yes deployment is set up correctly). What if I do not even set up a deployment? Can’t I work on a web app for a while without specifying the deployments? The deployment concern is a red herring and is not applicable to the problem I describe.

Setting up a project in the build path as a dependent project and under “references” worked fine for me to reference, use, compile my project with a dependent project. I’m using a clean install of 3.8.1

Other minor bugs in this release: There seem to be % symbols all over the Internet Tools preferences, as well as Workbench->Colors and Fonts->Structured Text Editor.name.

I don’t see the % in the Internet tools pref page, and the other one has been there since Eclipse 3.0 as far as I can tell (its also listed that way under the Key mapping preference page).

Make sure after upgrading to 3.8.1 you started Eclipse atleast once with the -clean command line argument.

[Armen Yampolsky]

@support-rkalla wrote:

Setting up a project in the build path as a dependent project and under “references” worked fine for me to reference, use, compile my project with a dependent project. I’m using a clean install of 3.8.1

Please have someone else confirm that the aforementioned bug and workaround continue to be relevant to this release. Create a web project with a single jsp page and no java sources. Have the jsp page import a package existing only in the project on which it depends. Do not add the classes directory to the build path, just the project itself. Do you see 0 problems in the problem view?

I don’t see the % in the Internet tools pref page, and the other one has been there since Eclipse 3.0 as far as I can tell (its also listed that way under the Key mapping preference page).
Make sure after upgrading to 3.8.1 you started Eclipse atleast once with the -clean command line argument.

With the -clean arg, the % symbols disappear and the aforementioned Provider and Feature Name fields are filled in. But as soon as I remove the arg and restart with my traditional -vmargs, both re-appear.

[Riyad Kalla]

I have asked someone else to look at this.

[Scott Anderson]

Yes, but the product no longer populates the “Provider” and “Plug-in Name” fields in any of the plug-in detail dialogs. An insignificant detail in what seems to be a super release. I think this is what many of us were expecting from 3.0 GA a week ago. Superb, and many many thanks!

Actually, this isn’t insignificant at all. It indicates that the workbench didn’t reset correctly so the features are not properly installed. Can you please exit Eclipse and restart it with the -clean option on the command line, similarly to this:
<path-to-eclipse>\eclipse.exe -clean

Once Eclipse restarts, the feature lists should be fully populated and proper functionality restored.

But as soon as I remove the arg and restart with my traditional -vmargs, both re-appear.

This begs the question, what are your traditional VM args?

If restarting with -clean once and then without it does not resolve the problem, you’ll likely need to close all editors and any MyEclipse perspectives, shutdown Eclipse, delete the <eclipse>/configuration directory and then restart. Additionally, if you used the manual install instructions you will need to reassociate MyEclipse to the Eclipse install again using Help > Manage Configuration… If you used the double-click installer, this step will not be needed.

[Robert Varga]

@support-scott wrote:

These are special instructions for using the MyEclipse update site to upgrade from MyEclipse 3.8.0 to 3.8.1. If you have a release of MyEclipse prior to 3.8.0 GA installed, please do not use the update site. Instead, use one of the downloadable platform-specific installers or the manual installation distribution. The update site is specifically built for upgrading only from 3.8.0 GA to 3.8.1.

The reason we’re providing a unique update site rather than using our default one is that we needed you to read and follow these specific instructions to work around a couple of bugs in the Eclipse platform update mechanism, specifically (Eclipse Bugs #70783/70716).
If you do not follow these instructions, you run a serious risk that the update will not be configured properly.

Here are the update steps:

First, you need to specify the update site manually by navigating to
Help > Software Updates… > “Search for new updates to install” > “New Remote Site…”
Enter a name you like (ie. MyEclipse 3.8.1 Update Site) with a URL of
http://www.myeclipseide.com/products/eworkbench/updates-3.8.0to3.8.1 and select “OK”
Check the new update site entry that is created and once Eclipse queries it and refreshes, select Next.
On the next wizard panel, select the line for MyEclipse 3.8.1 and select Next.
On the next wizard panel, select the terms of the license agreement and select Next.
On the final panel select Finish and then Install when you’re advised that the feature is not signed.

Once the installation completes, you’ll be presented with a dialog asking you if you want to restart.
Select *No*.
Once the dialog closes, immediately exit Eclipse.
In order to work around the Eclipse update bug referenced above, you now need to start Eclipse with the
-clean option. You can do this by modifying the alias you normally use to start Eclipse and passing it the commandline argument -clean. An example for a default Windows installation is shown below:

"C:\Program Files\eclipse-3.0\eclipse\eclipse.exe" -clean

When Eclipse restarts, MyEclipse 3.8.1 will be successfully installed. You can verify its presence by selecting Help > About Eclipse and then clicking on the MyEclipse icon to display the features installed.

If for some reason you let Eclipse restart itself rather than selecting “No” as instructed, simply exit the workbench, delete the log file at <workspace-location>/.metadata/.log and restart with
the -clean option to correct the installation.

We apologize for not being able to use our normal update site, but testing of it proved that these steps were needed in order to work around the Eclipse update bug and ensure a proper installation.

Two questions:

1. What if I have different workspaces specified with -data? Do I need to run eclipse with -clean on each workspace?

2. Does this also concern manual installs, or only installer installs?

Regards,

Robert

[Scott Anderson]

Robert,

Good questions.

1. What if I have different workspaces specified with -data? Do I need to run eclipse with -clean on each workspace?

Once on any of the workspaces should be fine. The configuration is stored in the Eclipse installation directory, not the workspace. You can verify proper update after relaunching with each workspace by displaying Help > About Eclipse and clicking on the MyEclipse icon. If all the features are listed and all the detail provided, you’re set.

2. Does this also concern manual installs, or only installer installs?

Both.

[Armen Yampolsky]

Hi Scott,
@support-scott wrote:

Actually, this isn’t insignificant at all. It indicates that the workbench didn’t reset correctly

Right, that makes sense.

But as soon as I remove the arg and restart with my traditional -vmargs, both re-appear.

This begs the question, what are your traditional VM args?

-Xms128m -Xmx128m

If restarting with -clean once and then without it does not resolve the problem, you’ll likely need to close all editors and any MyEclipse perspectives, shutdown Eclipse, delete the <eclipse>/configuration directory and then restart.

Thank you, that did the trick — I no longer need to specify -clean in my args. The web project dependency bug which was introduced in the GA release and which I describe above still persists, however. In addition, dependencies do not get deployed according to the paradigm used in 3.8beta2 — i.e., classes in projects on which a web project depends, in addition to external libs defined in dependent projects, do not get deployed. Deployment policies are ignored.

[Riyad Kalla]

ayampols,
Have you double checked your deployment settings? I’ve seen a few people report that after upgrading the deployment policies got reset so they had to fix them back up again. Also make sure you are running the 3.8.1 update (which I assume you are).

[Armen Yampolsky]

Hi Riyad,
@support-rkalla wrote:

ayampols,
Have you double checked your deployment settings?

Yes, in fact not only are they set in the workspace but also in the project itself, just in case.

I’ve seen a few people report that after upgrading the deployment policies got reset so they had to fix them back up again. Also make sure you are running the 3.8.1 update (which I assume you are).

Yes I am running 3.8.1, and now with the quickfix. To summarize, here are my findings for web apps:
(1) Classes in dependent EJB projects are not visible to jsp pages.
(2) No rebuild occurs if java build path is modified.
(3) On manual clean/rebuild, package view only displays build errors in the first jsp page that (incorrectly) fails, all others appear as if they have no build problems.
(4) If you use the workaround mentioned in this thread
http://www.myeclipseide.com/PNphpBB2+file-viewtopic-t-3283.html
compilation errors disappear (well first you have to do a manual clean/rebuild). However, those classes do not get deployed with the web project.
(5) External jars specified in the dependent project do not get deployed, even though the deployment policy specifically instructs it.

There is an easy way to reproduce this, and I would be very interested if someone could confirm it. Create one EJB project with a single class, no need to add fields or methods, just make sure it’s in some non-default package. Create a second web project with no sources, but a single jsp page. Add first project as a dependency. At the top of the jsp page, import the package in which the first project’s class belongs. Any errors? Now change the build path, add the classes directory from the first project. Does the web project rebuild? If not, perform a manual rebuild. Now double check the deployment policy, make sure dependencies are set to deploy. Now deploy. Did the class from the first project get deployed? If all goes well for you, then my installation is hosed and I’ll have to do a clean re-install, but I don’t want to go through this effort until someone confirms the validity or lack thereof of my observations.

Much Thanks!
-Armen

[Author]

Posts