brettporter wrote:
>
>
> On 01/03/2010, at 10:14 PM, Marc Lustig wrote:
>
>>
>> Hi there,
>>
>> I have just created MRM-1351 and have a couple of questions:
>>
>> 1) supported protocols
>> Maven Deploy Plugin supports next to DAV also FTP- and SSH-based artifact
>> deployment.
>> Which of those additional protocols does Archiva support?
>> Accordingly, which is the proper place for a generic implementation of
>> the
>> hashcode-based artifact validation?
>
> Neither natively - it does however scan the file-system, but it is not
> possible to reject it at this stage so the current behaviour of reporting
> the problem is appropriate.
>
>>
>> 2) getting the hashcode of the local repo
>> The maven-deploy-plugin does not support to specify a parameter like
>> "sha-hashcode", neither for the deploy nor the deploy-file subgoal. How
>> then
>> could Archiva possibly get the hashcode of the local repo from?
>> This appears to me a major pre-condition to implement this ticket.
>
> Sorry, this was my mistake - I thought that Maven uploaded the checksum
> first so that it could be used as the basis for determining if the
> artifact was correct.
>
> It seems the alternative might be needed, where upon uploading the
> checksum, if incorrect the checksum and the artifact are deleted. This can
> be considered reasonable behaviour as there is little risk of deleting a
> previously correct artifact (snapshot always deploy to a new timestamp,
> and releases should be blocked from redeployment, never reaching this
> option). On the downside, the artifact has already been correctly uploaded
> and if the checksum is never sent, it will be retained in the repository.
> However, this more closely matches your problem as it seems it is the
> checksums that are being uploaded incorrectly?
>
> - Brett
>
What we need is a process to automatically verify the integrity of an
artifact by uploading a local hashcode. Ideally, the verification takes
place in a single transaction (HTTP-request).
I suppose modifying the deploy:deploy goal is not practical, as it may have
impacts for a wide range of Maven users, and the Maven leaders will probably
veto against it.
But what do you think about adding a subgoal "verify" to the deploy plugin?
That way, the following call would deploy and verify an artifact, using -
well - not a single transaction, but at least a single mvn-call:
"deploy:deploy deploy:verify"
The deploy:verify subgoal could presume that Maven has been configured to
create hash-codes in the local repo. So what deploy:verify could basically
do is simply uploading an ordinary artifact .md5 or .sha1 using DAV.
Archiva identifies the verification task based on the file-suffix.
What will Archiva do:
- compares the uploaded hashcode with the one that has been created
- in case the hashes match: return HTTP 200 (OK)
- in case the hashes do NOT match: all Archiva-artifacts for the given
version (jar, pom, hashes, xml, etc.) will be deleted. returned is HTTP 400
(?) to indicate that the hashes did not match
The deploy:verify subgoal then outputs corresponding messages.
Failed verification should result in a BUILD ERROR message, of course.
--
View this message in context:
http://old.nabble.com/MRM-1351%3A-please-advise-tp27742269p27744435.html
Sent from the archiva-dev mailing list archive at Nabble.com.
