[rogue_dev]

I have an older library JAR file.

So I go to Project/ Properties/ Java Build Path, highlight and remove the older JAR. I then Add External JAR, and choose the library JAR.

I see that the new JAR is now shown in the Project Explorer. I also see that the project is being deployed (usage bar in the lower right status bar). However when I browse to the Tomcat directory to where the libs should be, I still see the old library JAR.

I know I can do a full redeploy. Should this be automatic?

Oh yes, I had the application running at the time (you get used to hot-swappable code…), maybe that is it? After I killed the application, the new JAR was not deployed.

Barring a full deployment, is there a way to selectively deploy a library JAR?

[Riyad Kalla]

Rogue,
Good questions, there are a few things at work here that explain why you saw this.

1) Build events trigger the deployer with exploded deployments. So your JAR should have been deployed.
2) The reason this likely didn’t happen is that the app server had locked the JAR, so when the autodeploy attempted to deploy, it collided with the locked JAR and silently failed.
3) After restarting the app server, that didn’t effect the deployment at all because the autodeploy step already tried to deploy and failed.

So the take-away point here is to only try and deploy libraries to stopped application servers. Deployment of other resources shouldn’t be a problem though and those can be deployed to a running app server.

Linux/Unix and Mac don’t suffer from locked files, but if you are on Windows you will need to watch out for this.

[rogue_dev]

Fair enough.

Could an popup error message be added then, so when this happens it does not fail silently?

Could a menu option be added, so when you RMB on a library jar, ME can deploy just that jar?

Thanks.

[Riyad Kalla]

Rogue,
Yes something needs to be added to take care of this use case, I’ve filed it as a bug and see if it can get addressed.

[Author]

Posts