Hi Marcos, I think you're right that this lies outside the scope of Artifactory's functionality. It's a while since I've used Java for real but I can think of a few possibilities.
One would be to split your WAR into multiple WARs and deploy/download them separately. A quick web search turned up a few questions and answers about this: * http://stackoverflow.com/questions/7727100/multiple-war-files-for-a-single-webapp-or-context * http://tomcat.10.x6.nabble.com/Multiple-war-files-for-the-same-application-context-td2086213.html * http://www.theserverside.com/discussions/thread.tss?thread_id=31459 * http://programmers.stackexchange.com/questions/178290/why-cant-wars-share-session-info Another would be to manually download the WAR at your end, unpack it, work out the difference compared to the set of files at the client end, then only send the changed files. Sending only the diffs could be done with an established tool like rsync or Unison (http://www.cis.upenn.edu/~bcpierce/unison/). I don't know how well that plays with the normal behaviour of WAR containers, though. Maybe there's some tool for diffing WARs, sending the diff, then updating the existing WAR??? Lastly, this might be a dumb idea but, depending on when your clients actually need the changes, you might be able to send the changes to them as soon as you've deployed them to Artifactory, and then only properly deploy them later. That is to say, it would still take 5 hours to download, but it would be 5 hours when your clients were busy with something else :-) Hope some of that helps, Hugh Greene, Senior Software Developer Toshiba Medical Visualization Systems Europe, Ltd Bonnington Bond, 2 Anderson Place, Edinburgh EH6 5NP, UK Tel + 44 (0)131 472 4792 / Fax + 44 (0) 131 472 4799 http://www.tmvse.com / mailto:hgre...@tmvse.com DISCLAIMER Unless indicated otherwise, the information contained in this message is privileged and confidential, and is intended only for the use of the addressee(s) named above and others who have been specifically authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message and/or attachments is strictly prohibited. The company accepts no liability for any damage caused by any virus transmitted by this email. Furthermore, the company does not warrant a proper and complete transmission of this information, nor does it accept liability for any delays. If you have received this message in error, please contact the sender and delete the message. -----Original Message----- From: marcos.tonina [mailto:marcos.ton...@outlook.com] Sent: 01 April 2016 19:38 To: artifactory-users@lists.sourceforge.net Subject: [Artifactory-users] Deploy and download just changed files Hi all. We are moving to Maven + Jenkins + Artifactory in our big project and we have now the following question. On this days, we delivery the binaries with Subversion, so, after a request, we merged the fixes with the binaries to a stable branch and updated the Tomcat in our clients server selectively -ticket by ticket-. Now we have a CI process including Maven where after each commit, we compile and test our code and send our war to Artifactory. We have never used war files before, since using SVN was enough. I know that we have big problems with security, performance, etc. That's the reason that is moving us to change. The problem that we have now is that since our war has 600MB of length, it is not viable to download all again just for a JS change, for example. So it is not good for our clients to say "ok, now we have a robust method for deployment, but yesterday, with the old approach, you had the fixes in 2 minutes, and now it takes 5 hours to download all the binares" Do Artifactory has an approach to this kind of problems in deployment? I know that it has a checksum hash to manage the binares internally, but I supose that the deployment itself is not a direct matter of Artifactory. If not, Is there somebody that dealed with this kind of situations before? Because I fought hard to implement this architecture, and now it seems like everything is lost, because it is not viable to deploy in this way to our clients and maybe we should go back to SVN to deliver our binaries. I hope that you can show me a light a the end of the tunnel. Best regards, Marcos -- View this message in context: http://forums.jfrog.org/Deploy-and-download-just-changed-files-tp7580875.html Sent from the Artifactory - Users mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 _______________________________________________ Artifactory-users mailing list Artifactory-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/artifactory-users ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ ------------------------------------------------------------------------------ _______________________________________________ Artifactory-users mailing list Artifactory-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/artifactory-users
