|
»
»
archiva source code
|
View:
New views
11 Messages
—
Rating Filter:
Alert me
|
 |
archiva source code
by geoffrey.twesige
::
Rate this Message:
Hi, when uploading artifacts to an archiva repository from the command
line using mvn deploy:deploy-file .............. Does anyone know which class of the archiva source code and what section handles this? Any help about this will be very appreciated. 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 |
|
|
Re: archiva source code
by brettporter
::
Rate this Message:
On 17/03/2009, at 1:45 AM, <geoffrey.twesige@...> <geoffrey.twesige@... > wrote: > Hi, when uploading artifacts to an archiva repository from the command > line using mvn deploy:deploy-file .............. Does anyone know > which > class of the archiva source code and what section handles this? Any > help > about this will be very appreciated. RepositoryServlet in archiva-webdav. What's the problem? Cheers, Brett -- Brett Porter brett@... http://blogs.exist.com/bporter/ |
|
|
RE: archiva source code
by geoffrey.twesige
::
Rate this Message:
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. Thanks again -----Original Message----- From: Brett Porter [mailto:brett@...] On Behalf Of Brett Porter Sent: 17 March 2009 03:10 To: dev@... Subject: Re: archiva source code On 17/03/2009, at 1:45 AM, <geoffrey.twesige@...> <geoffrey.twesige@... > wrote: > Hi, when uploading artifacts to an archiva repository from the command > line using mvn deploy:deploy-file .............. Does anyone know > which > class of the archiva source code and what section handles this? Any > help > about this will be very appreciated. RepositoryServlet in archiva-webdav. What's the problem? 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 |
|
|
Re: archiva source code
by brettporter
::
Rate this Message:
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/ |
|
|
RE: archiva source code
by geoffrey.twesige
::
Rate this Message:
Thanks a lot. I will have a go and if the hack works, then I will submit
a patch. -----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 |
|
|
RE: archiva source code
by geoffrey.twesige
::
Rate this Message:
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 |
|
|
Re: archiva source code
by brettporter
::
Rate this Message:
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/ |
|
|
RE: archiva source code
by geoffrey.twesige
::
Rate this Message:
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 |
|
|
Re: archiva source code
by brettporter
::
Rate this Message:
I don't see anything here that attempts to block, and not sure why you
are creating a new file object. I was thinking of something along the lines of: if ( isCollection() && inputContext.hasStream() ) // New File { if ( exists ) { throw new DavException( HttpServletResponse.SC_FORBIDDEN, "You can't overwrite resources already in the repository" ); } ... With a more descriptive error message and a configuration check. Cheers, Brett On 24/03/2009, at 10:39 AM, <geoffrey.twesige@...> wrote: > 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 > -- Brett Porter brett@... http://blogs.exist.com/bporter/ |
|
|
RE: archiva source code
by geoffrey.twesige
::
Rate this Message:
Ok, I didn't notice that there was already an
exists=localFile.exists().....so there was no need to create a new file object. The code below looks like something that I can expand on. One more question, What exactly do you mean by a configuration check? Cheers again -----Original Message----- From: Brett Porter [mailto:brett@...] Sent: 23 March 2009 23:59 To: dev@... Subject: Re: archiva source code I don't see anything here that attempts to block, and not sure why you are creating a new file object. I was thinking of something along the lines of: if ( isCollection() && inputContext.hasStream() ) // New File { if ( exists ) { throw new DavException( HttpServletResponse.SC_FORBIDDEN, "You can't overwrite resources already in the repository" ); } ... With a more descriptive error message and a configuration check. Cheers, Brett On 24/03/2009, at 10:39 AM, <geoffrey.twesige@...> wrote: > 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 > -- 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 |
|
|
Re: archiva source code
by brettporter
::
Rate this Message:
On 24/03/2009, at 11:52 AM, <geoffrey.twesige@...> wrote: > Ok, I didn't notice that there was already an > exists=localFile.exists().....so there was no need to create a new > file > object. The code below looks like something that I can expand on. One > more question, What exactly do you mean by a configuration check? > Cheers again I think it would be unwise to add this without a way to enable/disable it. Once you have the block working, the next step will be to make it configurable. You'll notice there is a ManagedRepositoryConfiguration object in the class already - that's where it should be placed. Cheers, Brett -- Brett Porter brett@... http://blogs.exist.com/bporter/ |
| Free embeddable forum powered by Nabble | Forum Help |
