I have strong web-developer background, where in order to show client a demo I've uploaded a solution to demo environment and sent over a link. If case client asked to make changes, I did them in PhpStorm, dev-tested on local env, deployed in one-click from IDE and asked them to reload the page. In was that simple and very efficient.

Now, I am working in Java and I deeply miss those efficiency I had with PHP. Demo deployment stays simple, but changes are a total mess. I need to:

  1. Rebuild the bundle with Maven;
  2. Upload 100Mb to Nexus;
  3. Run a deployment via a specialized tool, which downloads 100Mb, erases old deployment and deploys everything again.

Most of the JARs inside the bundle - 3rd party libs - never change. Redeploying them seems inefficient.

I could use JRebel or tools of that kind, but I am not in the position to make the organization buy proprietary software.

I believe there are teams out there that couldn't rely on paid software too. How to do dev-deploy-test cycle faster by implementing smart architecture and using free tools?

Update: Take my apologies, if the question tastes a bit ranty. What I'd like to know is How do you dev-deploy-test at wherever you work? Only non-interpreted Java-like programming eco-systems are in scope of the question.

  • If you don't run your build server locally, uploading 100 MB from the build server to the web server shouldn't take more than a few seconds. Mar 3, 2016 at 8:16
  • @CodesInChaos That's what I am asking about: is that a common practice in Java EE world or we just missing something in our process? Mar 3, 2016 at 8:25
  • 2
    Voting to close. This sounds like a rant disguised as a question...
    – Andres F.
    Mar 3, 2016 at 13:41
  • 1
    For the specialized tool thing, you should not need that, you could perfectly have a maven on your production server that when you execute a command with given parameter get the last version of it in the nexus and install it on the server properly.
    – Walfrat
    Mar 3, 2016 at 13:56
  • 1
    @AndresF. I think there is an acceptable question here, and I agree that its tone was a bit ranty. With 2,000 rep, you can edit a question to improve it and those edits will apply immediately.
    – user22815
    Mar 3, 2016 at 19:38

1 Answer 1


You can do patching yourself if you know what you're doing. But if you script that, you'll definitively have a problem: on each release you'll have to list every single changed files.

The goal of maven if to provide a full packaged delivery, so of course by default you'll have a 100mb war. This is the default behaviour because it's the easiest and the safest. But if you don't want to have always a 100MB delivery you can do the following:

  1. Get all the jar inside your current war that aren't from your code
  2. Put them in the library folder of your web server
  3. Set all your dependencies to the scope "provided".

This is a way to go, but if you ever update one of those provided components and forget to upgrade it on the server, you may have a failure and will probably have some trouble tracking it back from the update of the library.

But personnaly I consider that as long you don't have to upload 100MB yourself on each compilation for your own dev environment this doesn't worth any trouble, you're not supposed to deliver things that often so you can just wait a minute or two. I'll add this is why i use tomcat and not application server, I don't have any conflicts of already embedded library in the server. JBoss gave me a lot of trouble when I wanted to use a more recent version of jackson on it.

  • 1
    Aside - at a previous employer I wrote a perl script that took a .war (that also contained a java web start app) and had a clean build of ~400 mb and did created an incremental package (parameterized build based on two builds) and deploy script that got incrementals down to about 10-30 mb. This was a major savings/issue as we didn't want to do a deployment of 400 mb to ~300 store servers(or for that matter, the JWS was so that we didn't need to do a deployment to 16 registers * 300 stores). This incremental deployment did take a bit of infrastructure change though (preventing wrong builds).
    – user40980
    Mar 3, 2016 at 14:38
  • 1
    @MichaelT yes that's the way to go, either let maven doing the 400MB war that you copy/paste on all server or adapt the infrastructure to be able to receive custom incremental building and thoroughly tested. In my opinion anything mid-way will just be a failure.
    – Walfrat
    Mar 3, 2016 at 15:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.