If you add apache staging to your corp proxy and expose that to everyone you are mixing test and production. /me dislikes the concept.
The way I usually solve this is to have an additional corp repo-url that exposes the regular internal repo *and* staging. This url is used to test staging. (I have yet to come across a scenaro where multiple users share this ;) Kristian 2013/6/3 Stephen Connolly <stephen.alan.conno...@gmail.com>: > Now the issue with componentX-1.4 that you wan to test is one that only > shows up behind your corporate proxy, and you have a system set up with the > failing case and you dare not change anything... > > So you add the staging repo to your mirror, run the test case, and drop the > test artifact from the mirror as fast as you can... (Because creating a > separate mirror would require changing the test setup and resulting in > re-resolution again) > > The thing is that the test is a long test... And now you don't know who > else has got that invalid componentX-1.4 (because your test is still > failing) and when the fixed componentX-1.4 is released you may find a > nightmare tracking it down again. > > Somewhat contrived some might say, but that is the use case where this s > more critical > > On Monday, 3 June 2013, Robert Scholte wrote: > >> All nice ideas, but let's go back to a real usecase: >> >> Let's assume we're having an issue with componentX-1.4 >> If you weren't one of the testers, then this dependency was pulled from >> Maven Central. You can check out the code as specified in the tag, etc. >> etc. No issues here. >> But if you were one of the testers you must be sure that you're not using >> the staged version anymore, but the one from Maven Central. When reusing >> version numbers due to unsuccessful staged versions, you can only confirm >> it by comparing the *revisions* of both componentX-1.4 >> I think somehow (the rootcause of) MNG-5181 is related: if you're using an >> artifact originally from a staging repo and that repo has disappeared, the >> build must fail. You are forced to clean up these staged artifacts, so they >> are pulled from Maven Central. Only this way your local build is the same >> as any other developers build. >> As said before: - the actual release is the one in the dist-folder >> - tags are just an easy way to refer to a certain revision. >> - so if you want to be 100% sure you're checking out the correct source, >> use revisions and not tags (which means revision must be set during >> packaging, e.g in the manifest file). >> >> Robert >> >> Op Sun, 02 Jun 2013 22:43:02 +0200 schreef Benson Margulies < >> bimargul...@gmail.com>: >> >> I would consider it delux if the release plugin were enhanced to >>> support a more sophisticated mapping between artifact versions and >>> tags -- as per Kristian, wouldn't it be cool if it could iterate over >>> tags while repeating itself on customer-visible release numbers? I'd >>> help to code this is we had a collective understanding of how we >>> wanted it to work. >>> >>> ------------------------------**------------------------------**--------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > -- > Sent from my phone --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
