Problem: An issue has been identified with the MyEclipse 3.8.2 - 3.8.4 custom exploded deployment mechanism that results in the target location being removed to clear the way for the new deployment's content.

Scope: The following notice applies only to the MyEclipse 3.8.2 - 3.8.4 custom exploded deployment mechanism. All other deployment forms are not include in this notice.

Explanation: An issue has been identified with the MyEclipse 3.8.2 - 3.8.4 custom exploded deployment mechanism that results in the target location being removed to clear the way for the new deployment's content. Unfortunately this can result in unintended removal of important file system content if the root deployment folder is of critical importance. We wil be releasing a QF and updated installers shortly.

Two new measures will be introduced in the upcoming QuickFix (QF) to prevent removal of a critical directory during custom deployment:

1) Custom exploded deployment has been revised to only allow deployment to a non-existent folder. That is, you must specify the path to a new folder that will be created as part of the custom exploded deployment.

2) Undeployment of an exploded deployment will always present a warning message describing the impact of the operation on existing files. The user will be able to cancel the operation.


Recommendation: The short term workaround is to "always" specify a new folder as the target location for your custom exploded deployment. Do not deploy directly into an important critical system folder or user folder such as "C:\" or "C:\Program Files". But rather choose a new folder such as c:\<your deployment's name>, e.g., C:\mydeployments\MyEARProject.

Wayne Parrott
VP, Product Development
Genuitec, LLC

This issue has been addressed in QuickFix 2 and all installers were updated on 02/05/2005 09:30 CST (-6GMT)

More details are available here:
http://www.myeclipseide.com/index.php?name=PNphpBB2&file=viewtopic&p=29320#29320

This also happens with the Packaged deployment, which makes no sense at all (why would you want to delete the contents of the folder where you are creating a war file????).

I do have 3.8.4.QF2, and MyEclipse just deleted my Desktop when trying to update a war file created there. I would expect this behavior from the Exploded deployment, but NOT from the packaged one.

Alfonso.

Alfonso,
I cannot reproduce this behavior at all with exploded or packaged deployment. Packaged deployment will only erase the file that it created (the WAR file). Can you tell me how ot reproduce your steps?

OK, here is what happened:

- Choose Add Deployment
- Choose Packaged
- Choose Custom Location
- Choose Browse
- Select Desktop

My location changed to this:
C:\Documents and Settings\agonzalez\DesktopEnrollWeb

To me, this looked like a bug where there was a missing "\" characted, and I wanted the war file to go on the desktop....

At this point, you can imagined what happened. Never did I expect that location meant "This is the actual war file", and that my eclipse would assume "Delete the Desktop directory and replace it with a war file".

Regards,
Alfonso.

Alfonso,
I just did the following steps

1) Created directory: C:\Test\agonzalez\Desktop (to simulate your setup)
2) Created new Web Project named "EnrollWeb"
3) Opened Deployment tool, clicked Add
4) Chose Packaged & Custom Location (in that order, to follow you)
5) Hit browse, selected C:\Test\agonzalez\Desktop, GOT: C:\Test\agonzalez\Desktop (weird?)
6) Hit Finish, deployment was immediately marked Out of Sync
7) Hit "Remove" and the Desktop directory was removed, as you confirmed.

I have a feeling this is exactly what happened to you, and not the \DesktopEnrollWeb dir as you originally stated. Please note that I DID encounter the missing-slash problem earlier trying to reproduce this, but just now when I followed your steps exactly, it just used the dir name and didn't append any project name. I will report this immediately as high priority bug. Thank you for helping us find this, and we appologize for the loss of information; that is unacceptable.



Also it seems that in 3.8.4+QF2 this problem just became a "missing slash" issue, but in 3.8.4 it will actually erase the directory. That was one of the bugs we fixed in QF1 and 2.