- This topic has 9 replies, 4 voices, and was last updated 20 years, 3 months ago by
.
-
Posts
-
Hi –
When you deploy an ear (or some J2EE project) and there is an existing deployment, you are asked if you want to backup the remote resource or delete it.
For our project, we need a third option. Just overwrite existing deployment.
I know this might seem strange but we have modular system. There may be 4 other built and deployed already. When you are working from module 5, we just want to deploy its resources.
If this is not possible, could we get the source code for that module so that I can patch for our overwrite resource case?
Thanks…
DorothyDorothy,
Let me check with the team on this as I think your request is a good one and I can see in certain cases where you *know* what you want, you just want the deployer to copy out the files and stop pestering you so to speak…Can you elaborate more on how the overwrite feature is different from a delete + deploy process?
I can see in certain cases where you *know* what you want, you just want the deployer to copy out the files and stop pestering you so to speak…
For example does the concept and scope of J2EE Project relevant in your deployment requirements or do you have some other organizational concept that your are mapping onto the ME project structure and deployment model?
For example does the concept and scope of J2EE Project relevant in your deployment requirements or do you have some other organizational concept that your are mapping onto the ME project structure and deployment model?
We do have an J2EE application and have a simple ear with one web application. The complication is that our web application is combined from a set of functional modules (different file systems in CVS). Our modules can be dependent on other modules. Each module has its own source directories and webroot. We want a developer to run a setup step which deploys the dependent modules and then just work with their own module in MyEclipse deploying that module’s files.
Dorothy,
Do you mean that 1 person wants to deploy the EAR, then each module developer will be able to deploy their own Web Module portion to the location of the EAR such that their portion overlays the correct directory in the EAR’s deployed structure?@support-rkalla wrote:
Dorothy,
Do you mean that 1 person wants to deploy the EAR, then each module developer will be able to deploy their own Web Module portion to the location of the EAR such that their portion overlays the correct directory in the EAR’s deployed structure?Hi Riyad –
Yes, each developer overlays their own portion of the war within the ear.
Dorothy
Then I appologize, I didn’t realize this is what you were asking at first… this is a bit more complex. I will ask about this functionality.
Hi Riyad –
I am a little confused about the complexity. As far as I can tell, each developer has their own definition of the ear with a distinct war project. As long as that ear project can overwrite the pre-setup deployment, we should be fine. We already have tools and setup for the merged web.xml. Obviously, you know more about your product.
Dorothy
Let me see if I can weigh in and add a little clarity here.
When you deploy an ear (or some J2EE project) and there is an existing deployment, you are asked if you want to backup the remote resource or delete it.
For our project, we need a third option. Just overwrite existing deployment.Actually, overwriting is what the delete option does. It removes what was previously there and then puts the new deployment in the same location.
As far as I can tell, each developer has their own definition of the ear with a distinct war project. As long as that ear project can overwrite the pre-setup deployment, we should be fine.
If the full EAR definition includes all the modules and each developer has access to all the modules, then each developer will be able to redeploy just their pieces as they work on it using our exploded deployment and HotSync capabilities.
However, it sounds to me like you’ve got an automated process that takes some large set of modules and deploys them to a server directory in exploded format. Let’s call this the “full EAR”. Then you want each developer to be able to configure a smaller version of the full-EAR, call it a “sub-EAR” with the same name, but without all the modules in it, and then overlay the deployment of that portion of the entire EAR to the same location that you predeployed the full-EAR. In doing so, it’s supposed to overwrite whatever modules happen to be defined in the sub-EAR, but leave all other modules from the full-EAR, and I assume the full-EAR’s deployment descriptors, in tact. Did I state that correctly?
