"adrian(a)jboss.org" wrote : "pgier" wrote : | | If you try to download from the old location, it should give you a message that you need to point to the new location. | | What do you mean "give you a message"? | Why didn't Kabir's build pick up the same thirdparty dependencies that my build does? | | This is the key issue that needs to be resolved. How do we know this build is | reproducable given we're likely to have any old rubbish in our local repositories | from other maven builds? | | i.e. How can we be sure that we can checkout the JBossMC-2.0.0.GA tag from SVN | and rebuild the same binaries as we had when it was released 6 months earlier? | It should display a warning similar to this if you use the old location (sun-jaf): | [WARNING] While downloading sun-jaf:activation:1.0.2 | This artifact has been relocated to javax.activation:activation:1.0.2. | This file has been relocated based on maven recommendations: http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html | I'm thinking that the best way to handle reproducing old builds is to keep a copy of the contents of the local repo when doing a release. That way if an old release needs to be rebuilt, the local repository can be refreshed, and the build can be done off-line. I think the amount of "old rubbish" in our repository will be increased if we can never make any changes to files or directory locations. If we keep our release builds off-line without using any remote repository and we save the build environment, then we can be sure that we can redo the build. None of this is set up yet, but it is probably what needs to be done. Does this sound like a better solution? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062993#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...