Hello Ivan, the way I solved this problem in a company I worked for previously is as follows :
- do not have separate release builds and continuous integration builds - decide in an ad-hoc way which build is going to be used as a release - purge the builds which do not make it to a release What we did is we were storing the artefacts in a WebDAV based repository. At deployment time we would set WebDAV properties on the folder holding the version being deployed. Afterwards it is a matter of writing a program/script/build file which iterates over all versions and removes the versions which never made it to PROD and are older than 2 weeks (adjust these rules to whatever is accepted by the community of your software development project). So by doing this you gain in not having to decide in advance which revision will have all the blessings to go to PROD, and not having to maintain different release and continuous integration build processes. I find that maintaining separate build processes for the same software is an anti-pattern. Regards, Antoine On Jan 12, 2015, at 11:23 AM, ivan frias <frias.i...@gmail.com> wrote: > Hi, > Currently I am building an app using ant + ivy ( as dependency manager ). > I've followed the multi-project tutorial and configured my project > accordingly. Everytime I bulild the application it gets publish to shared > repository., what brings some overhead in therms of disk space. > > I'd like to know the best way to generate a unique development version of > my EAR ( for testing ) and only publish to local/shared repository when > releasing. > > Best regards, > Ivan Frias
