Re: archiva source code

> Here is a simple modification I have made to block duplicate
> deployments. Any idea what I could be missing because it  is not  
> working
> properly. This is in the addMember method.
>
>
> if ( isCollection() && inputContext.hasStream() ) // New File
>        {
>         File file  = null;
>            FileOutputStream stream =
> null;
>            try
>            {
>             file = new
> File(localFile.toString());
>             if (!file.exists()){
>             System.out.println("
> does not EXIST..." +localFile.toString());
>            
>             stream = new
> FileOutputStream( localFile );
>             IOUtils.copy(
> inputContext.getInputStream(), stream ); //takes in one file & then
> sends it. send another one after this
>             }
>            
>            }
>           // catch ( IOException e )
>            catch ( Exception e )
>            {
>                throw new DavException(
> HttpServletResponse.SC_INTERNAL_SERVER_ERROR, e );
>            }
>
>
>
> -----Original Message-----
> From: Brett Porter [mailto:brett@...]
> Sent: 23 March 2009 23:34
> To: dev@...
> Subject: Re: archiva source code
>
> Not quite sure what you are referring to... addMember takes an
> inputContext with a stream - the servlet container and jackrabbit
> handle taking this directly from the client and passing in a stream
> that is written to the localFile.
>
> What you want to do is, based on the value of exists and the new
> configuration option, fail.
>
> Cheers,
> Brett
>
> On 24/03/2009, at 10:29 AM, <geoffrey.twesige@...> wrote:
>
>> Hi again,
>> I have just started having a go at fixing the issue below. Before
>> archiva starts copying artifacts to the version directory, 1.e., 4.1,
>> 9.0, 1.2.3 and so on...., it creates it somewhere first. Does anyone
>> have an idea  where? I have commented out the 'addMember' method in
>> the
>> 'ArchivaDavResource' class and this confirms that the version
>> directory
>> is not created there. Does anyone know where it is created? If I can
>> find the answer to this, then the rest should be trivial.
>> Thanks.
>>
>> -----Original Message-----
>> From: Brett Porter [mailto:brett@...] On Behalf Of Brett
>> Porter
>> Sent: 17 March 2009 10:07
>> To: dev@...
>> Subject: Re: archiva source code
>>
>>
>> On 17/03/2009, at 8:57 PM, <geoffrey.twesige@...>
>> <geoffrey.twesige@...
>>> wrote:
>>
>>> The problem is that Archiva accepts deployments of artifacts that
>>> already exist in the repository. I have already modified the code in
>>> the
>>> UploadAction class to block off any duplicates via the upload
>>> section on
>>> the Archiva UI and now I am trying to do the same for Webdav. I am
>>> open
>>> for suggestions if anyone has some, because it seems like doing the
>>> same
>>> for deployments via Webdav is going to be a tough hack.
>>
>> ArchivaDavResource has an addMember resource that takes care of this,
>> so you can make the modification there.
>>
>> If you are able to also add some configuration on the managed
>> repository as to whether it should allow this or not, this would be a
>> great change to contribute back. Will you be able to submit a patch
>> for your changes?
>>
>> Cheers,
>> Brett
>>
>> --
>> Brett Porter
>> brett@...
>> http://blogs.exist.com/bporter/
>>
>>
>>
>>
>> This e-mail (including any attachments) is confidential, may contain
>> proprietary or privileged information and is intended for the named
>> recipient(s) only. Unintended recipients are prohibited from taking
>> action
>> on the basis of information in this e-mail and must delete all  
>> copies.
>> Nomura will not accept responsibility or liability for the accuracy  
>> or
>> completeness of, or the presence of any virus or disabling code in,
>> this
>> e-mail. If verification is sought please request a hard copy. Any
>> reference
>> to the terms of executed transactions should be treated as
>> preliminary only
>> and subject to formal written confirmation by Nomura. Nomura
>> reserves the
>> right to monitor e-mail communications through its networks (in
>> accordance
>> with applicable laws). No confidentiality or privilege is waived or
>> lost by
>> Nomura by any mistransmission of this e-mail. Any reference to
>> "Nomura" is
>> a reference to any entity in the Nomura Holdings, Inc. group. Please
>> read
>> our Electronic Communications Legal Notice which forms part of this
>> e-mail:
>> http://www.Nomura.com/email_disclaimer.htm
>>
>
> --
> Brett Porter
> brett@...
> http://blogs.exist.com/bporter/
>
>
>
>
> This e-mail (including any attachments) is confidential, may contain
> proprietary or privileged information and is intended for the named
> recipient(s) only. Unintended recipients are prohibited from taking  
> action
> on the basis of information in this e-mail and must delete all copies.
> Nomura will not accept responsibility or liability for the accuracy or
> completeness of, or the presence of any virus or disabling code in,  
> this
> e-mail. If verification is sought please request a hard copy. Any  
> reference
> to the terms of executed transactions should be treated as  
> preliminary only
> and subject to formal written confirmation by Nomura. Nomura  
> reserves the
> right to monitor e-mail communications through its networks (in  
> accordance
> with applicable laws). No confidentiality or privilege is waived or  
> lost by
> Nomura by any mistransmission of this e-mail. Any reference to  
> "Nomura" is
> a reference to any entity in the Nomura Holdings, Inc. group. Please  
> read
> our Electronic Communications Legal Notice which forms part of this  
> e-mail:
> http://www.Nomura.com/email_disclaimer.htm
>