Although it is slightly off-topic (I assumed our Apache environment), but
also in this case: as long as componentX-1.4 was staged and not released,
developers must adjust their settings.xml to test componentX-1.4.
So they should be aware that this component was not released and should
remove it afterwards (when the release is dropped(?)).
So how important is tracking down if Maven could verify that your version
of the componentX-1.4 is not the same as the released componentX-1.4? In
such case keeping your version is useless, because your build will always
be different then the one created by other developers.
IIUC even though we say "final version are only downloaded once", Maven3
keeps verifying it with the original repository.
A worst case scenario would be if the build-server pulls in staged
artifacts (because someone specified the staging URL and committed a
pom.xml with this artifact as dependency) and the repository is used by
all jobs. This might lead to false-positive test results or false-negative
test-results.
When you're using a repository-manager without staging support, then the
story is a bit different. In that case artifacts immediately end up in the
company-repository and you'll loose track of who is using is. In such
cases you should never redeploy with the same version.
Robert
Op Mon, 03 Jun 2013 19:49:19 +0200 schreef Stephen Connolly
<[email protected]>:
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 <
[email protected]>:
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: [email protected]
For additional commands, e-mail: [email protected]
------------------------------**------------------------------**---------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
