The MyEclipse project deployment is based on the WTP application server framework. You can install any WTP service connector into the MyEclipse workbench. MyEclipse provides a large set of popular WTP service connectors with special features that can be deployed to keep pace with project resources during development. The MyEclipse Enterprise Workbench deploys Web, EJB, and enterprise applications in an exploded or packaged archive to any application server enabled by MyEclipse. The JEE standard commands deploy a packaged file structure under each application type. Typically, JEE applications are deployed into the production environment as an archived version of their respective JEE command file structure, also known as the deployment of the packaged archive. The exploded archive deployment includes creating the original folder of the application and the file structure directly available on the application server, without involving archiving. MyEclipse can deploy JEE projects to one or more application servers in an exploded or packaged archive. When the JEE project is deployed as an exploded archive, the MyEclipse Deployment Service uses the "on-demand" technology to keep track of project status. Note that the exploded archive deployment is not a standard form of JEE deployment. Therefore, the deployment service constrains the deployment form and the project should be supported by the target deployment server. Deploying Service Wireframe Deployment Models The choice of Packaged archive deployments is different from the exploded deployment and does not support incremental or automatic archive updates. Therefore, on project editing, the Packaged deployment will be out of sync with its source project. On-demand synchronization of exploded deployments does not suffer from this synchronization issue, and project deployment enables continuous real-time updates to the compilation of source projects. Both deployments have their own advantages and disadvantages. For example, packaged deployments are less efficient than exploded deployments. This is because updates to packaged deployments using incremental changes require rebuilding the entire archive. After a resource change, the packaged deployment needs to do the same amount of work as the entire project update. The benefit of the packaged deployment model is that it is the JEE deployment standard and format for product deployment. Therefore, all application servers support the packaged deployment mode. Exploded deployment is fast and straightforward. Incremental changes to the project are immediately reflected on the server where the project is deployed. However, it does not support spanning all JEE application servers in a standard way. Deployment of the deployment management facility MyEclipse is managed through the use of the deployment manager. This window allows users to see existing deployments, add new ones, and remove old ones. The following figure depicts a project deployed on a single server. Some points of managing a deployment window deployment: When a JEE project is deployed, it will maintain this deployment until the project is removed or the deployment is removed. The undeployment operation is initiated by the user directly by requesting the release of the command or indirectly as a result of the “deploymenttermination event”. Deploy continuous coverage through an Eclipse session. Therefore, you may disconnect MyEclipse and reconnect back in a while and resume deployment management and or on-demand deployment. The Exploded project deployment physically replicates the project runtime environment resources to a location that is automatically deployed by the target application server. Except when context-root is the default application, the deployment of the web project is named after the project's context-root. That is, in the case of context-root=‘/’ the deployment is named according to the default application name of the application server. The default application name in Tomcat is “root”. The Web Module project, also known as the Enterprise Project Module, is deployed under a separate context-root that specifies when to add a web project to an enterprise project. During the deployment process, if the resource exists in the server, you can choose to delete the remote resource and back up the resource after the main deployment is released, or undeploy the process. De-deployment involves physically removing deployment resources from the deployment area of the application server. If the conflicting resource falls back during the project deployment phase, it is because it will undeploy these resources and the resources will be restored to their previous form. Resource backup handles the problem of conflicting target resource renaming by adding the suffix ".myeclipse.bak" as the base name of the resource. Deployment Termination Events To maintain the integrity and relevance of the deployment, the deployment service automatically cancels the JEE project deployments that have undergone major changes. The following sections identify the events that trigger the termination of each JEE type. Web project termination event Web project shutdown + MyEclipse restart Web project Delete Web project Rename Web project context-root revision EJB project termination event EJB project shutdown + MyEclipse restart EJB project Delete EJB project Rename enterprise project termination event EAR project shutdown + MyEclipse Restart EAR project Delete EAR project Rename Add a module project Remove a module project Release a module project deployment Xiaobian recommended "MyEclipse crack version download" This article comes from [system home] www.xp85.com