On Monday, 3 June 2013, Kristian Rosenvold wrote: > 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.
The *point* is what happens when your test case machine is pointing to the proxy. If you switch that to a different URL _maven.repositories will kick in and re-resolve potentially breaking your test case. The only way I can see out of such is to edit the test machine's hosts file so that the DNs name gets resolved to a different server and that assumes the proxy is referenced by DNS and not eg https:/ 10.0.0.5/nexus/groups/public/ I did say this is likely a rare case, but it is the case that would force burning version numbers, and the exception tests (or proves in old English) the rule (Anyway vote is over, so issue is moot. I don't care enough to call a second vote) > (I have yet to come across a scenaro where multiple > users share this ;) > > Kristian > > > 2013/6/3 Stephen Connolly <stephen.alan.conno...@gmail.com <javascript:;> > >: > > 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 <javascript:;>>: > >> > >> 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<javascript:;> > >>> For additional commands, e-mail: dev-h...@maven.apache.org<javascript:;> > >>> > >> > >> > ------------------------------**------------------------------**--------- > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org <javascript:;> > >> For additional commands, e-mail: dev-h...@maven.apache.org<javascript:;> > >> > >> > > > > -- > > Sent from my phone > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org <javascript:;> > For additional commands, e-mail: dev-h...@maven.apache.org <javascript:;> > > -- Sent from my phone
