Um, did I miss something, but what is a unreleased (ie for it to be pulled,
then it has to be right?) artifact doing in central to start with?

-Chris


On Tue, Jun 4, 2013 at 3:32 AM, Robert Scholte <[email protected]> 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].**org<[email protected]>
>> For additional commands, e-mail: [email protected]
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: 
> [email protected].**org<[email protected]>
> For additional commands, e-mail: [email protected]
>
>

Reply via email to