[bob.bateman]

I’m working with a Web app project, and wanting to use two deployments at the same time. One deployment goes to a Tomcat 5 server, the other to a custom location packaged war. When manually deploying, both deployments function properly. When I modify something, say a JSP file, and the project auto-builds, the TC5 deployment runs automatically as expected, but the custom location/packaged deployment does not. It’s status goes to “redeploy” and I get the customary message about “…out of date due to changes in the underlying content…” I can then manually invoke “redeploy” and the deployment proceeds. There is no app server or version control involved in the custom deployment location, and it is not inside the project directory. I’ve tried the -clean command line option, Project->Clean, removing and re-adding deployments.

I’m using:

Eclipse 3.2.2
MyEclipse 5.5.1 GA
JRE 1.5.11

I believe I’ve seen this behavior with other combinations of versions, so I’m wondering if this is intended behavior in some way. I’ve also seen it in multiple projects and workspaces. Just to be clear – everything works correctly when manually running either deployment. The same behavior also happens even when the custom/packaged deployment is the only one configured.

My main question is: why doesn’t automatic redeployment work with custom/packaged?

[Riyad Kalla]

Bob, the behavior you are seeing is correct. Packaged deployments are not updated automatically. The reason for this is that to update an exploded deployment only requires copying out a single file. To update a packaged deployment, the entire package needs to be rebuild (without getting into the complexities of writing a JAR-diff deployer). And with a lot of our enterprise customers, a packaged deployment could be 20, 50 or 100 MB or more in size, so recreating that deployment automatically every time a file changes is a complete show-stopper for them.

Maybe changing your work habits to only re-create the packaged deployment when you need an updated WAR would cause you less of a headache?

[bob.bateman]

Riyad,

Your explanation of the reasoning makes sense – I knew it had to be something like that. I couldn’t find any reference to this behavior in any docs. If you don’t want to make this special behavior optional, then there should at least be a note in the deployment setup dialog.

Regarding work habits, this gets into the old argument about whether or not Eclipse is a suitable tool for generating productions builds (versus ant or other automatable build system). Without getting too far into it, let me just say that for my purposes, Eclipse is often sufficient for creating test builds, in the form of war file output to an external Tomcat instance.

It is frustrating to me that MyEclipse seems to have no automated way to create the deployment war. Why not have a “Deployment Builder” that does what MyEclipse does for deployment? If it was in the form of an optional builder that I could add to my project, then it would be up to me whether or not to use it.

[Riyad Kalla]

If you don’t want to make this special behavior optional, then there should at least be a note in the deployment setup dialog.

I agree… this is one of those “duh” moments… we should label that somewhere.

Regarding work habits, this gets into the old argument about whether or not Eclipse is a suitable tool for generating productions builds (versus ant or other automatable build system). Without getting too far into it, let me just say that for my purposes, Eclipse is often sufficient for creating test builds, in the form of war file output to an external Tomcat instance.

What I meant actually was based on 2 assumptions (that could be wrong?)
1) That your development build was the exploded deployment.
2) Your production build is your packaged deployment
3) Based on 1 and 2, I assumed you only needed to do #2 as you finished implementing features or fixing bugs… maybe once a day or so? So I figured popping out a new packaged deployment right before you needed it as opposde to every single time you changed any file would yield the same results. Again, this could be totally wrong.

It is frustrating to me that MyEclipse seems to have no automated way to create the deployment war. Why not have a “Deployment Builder” that does what MyEclipse does for deployment? If it was in the form of an optional builder that I could add to my project, then it would be up to me whether or not to use it.

I don’t understand your request here. How does making the deployment tool a builder sudden fix your problem? (please describe the use-case… there might be good cause for a feature request in here…)

[bob.bateman]

Oops, that wasn’t clear. What I was trying to ask is why the war builder doesn’t work like other builders? The current model hard-codes your assumptions that exploded=development and war=production. Actually, it seems like packaged deployment as currently implemented isn’t really deployment, it’s a build step that creates a war file. To make packaged deployment really useful, I think it would be better to think of it as two steps:

1. Invoke the war builder as the final build step (In Ant, the corresponding idea would be a “war” target, which runs the full compile target as a dependency, then creates a war file). (This is the same warfile builder that should be available as a normal builder, independent of anything to do with deployment.)

2. Invoke whatever app server integration is needed to reload the war file. I believe Tomcat for example can automatically reload a war file, but it has to be configured appropriately. Otherwise a server or context restart is needed. Of course it would be optimum for the build step to create the war file directly at the server, rather than adding another file copy step.

I guess I’m talking about two use cases here:

1. I have a pretty simple app (much less than 100MB), I need to generate a war file, and the MyEclipse generated war file is sufficient for my production purposes. I don’t want to put together another Ant script that just duplicates what MyEclipse is already doing internally.

2. I prefer to use a war file on my test server so I (or anyone on my team)
can simply grab the latest war file from the web server and know they got
the one they want, without having to go back into Eclipse or the build
system, or see if any commits have been made since the war file build, etc. I’d probably be willing to give up hot-replace to use this mode.

-BB

[Riyad Kalla]

1/2) This already happens, the deployer will “touch” the web.xml file which most app servers will recognize and reload the context when you use the “Redeploy” button from the deployment manager. Maybe that would help you?

1. Makes sense… you could setup a custom location deployment to whatever location you wanted to create the WAR file in, and whenever you needed to refresh the WAR, you open up the deployment dialog and hit Redeploy.

2. Definately makes sense.

[bob.bateman]

I think you may have missed a very important part of my request – I want all of this to happen as a part of auto-build -> auto-deploy – I don’t want to use the Redeploy button, or think about manual deployment after the project is configured.

[Riyad Kalla]

Bob,
I understood that part, but it would require reimplementing the packaged deployer to be incremental in nature. It’s something that has been requested 1 other time before and for the amount of work involved is something that management hasn’t prioritized yet over other features going into the releases.

I will add your comments to that request though, to let them know it’s still requested.

[Author]

Posts