archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deng Ching <och...@apache.org>
Subject Re: logic to prevent overwriting release-artifacts
Date Tue, 06 Oct 2009 03:46:09 GMT
Hi Marc,

Sorry for the confusion, I think the blocking of overwriting released
artifacts should be placed in the ArchivaDavResourceFactory instead of the
RepositoryServlet or RepositoryContentConsumer since that handles the
resource requests and that's where the artifact data is determined. You
might want to take a look at the processRepository(..) method where the PUT
requests are handled.

There's also the upload from the web UI to consider for this feature as it
is entirely separate from the DAV deployment. This is in turn handled by the
UploadAction in archiva-webapp :)

Thanks,
Deng

On Mon, Oct 5, 2009 at 11:58 PM, Marc Lustig <ml@marclustig.com> wrote:

>
> Ok, thanks, so if I understand you correct, we should not the
> RepositoryServlet, but the repo-consumer that you proposed, right?
>
>
> Deng Ching-2 wrote:
> >
> > Hi Marc,
> >
> > Please see in-line comments below :)
> >
> > On Mon, Oct 5, 2009 at 7:32 PM, Marc Lustig <ml@marclustig.com> wrote:
> >
> >>
> >> Deng, Brett, et al
> >>
> >> if you give me some instructions to implement this straight away, I will
> >> be
> >> glad to do that.
> >>
> >>
> >>
> >> Marc Lustig wrote:
> >> >
> >> > yes please - the initial call to deploy the artifact is done in #124
> in
> >> > RepositoryServlet right?
> >> > (Deng mentioned that the repo-consumer is called immediately after
> >> > deploying the artifact, but I guess the check should be done before
> the
> >> > deployment is triggered.)
> >> >
> >> > So could you give me a hint how to retrieve the information necessary
> >> to
> >> > do the check:
> >> > - target repo and location in the repo in the fs (?)
> >>
> >
> > You can get this from ArchivaConfiguration, I think this is already a
> > component of the repo-consumer.
> >
> >
> >> > - artifact data (groupId, artifactId, ...)
> >>
> >
> > This is usually passed in to the repo consumer. If you want to check for
> > the
> > existing artifact in the database, you can get it through the
> > ArtifactDAO..
> >
> >
> >> >
> >> > What is the proper way to do that lookup? via File.exists(), or not
> >> better
> >> > using some Archiva-method like
> >> > SomeStaticSingleton. getRepo(reponame).artfifactExists(groupId,
> >> > artifactId, ....)
> >> >
> >>
> >
> > I think there is a component for this in the repository-layer module,
> I'll
> > get back to you on this one :)
> >
> > Thanks,
> > Deng
> >
> >
> >> > That would be better software design than looking up in the fs...
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > brettporter wrote:
> >> >>
> >> >>
> >> >> On 25/09/2009, at 7:56 PM, Marc Lustig wrote:
> >> >>
> >> >>>
> >> >>> OK, I agree that instead of adding a permission for overwriting
> >> >>> artifacts it
> >> >>> should be sufficient to delete that particlar artifact. The case
> >> >>> when you
> >> >>> have to overwrite a whole bunch of artifacts in once should be
> >> >>> rather rare.
> >> >>>
> >> >>> Yeah, I already filed that a while ago as MRM-992.
> >> >>> And even that was a duplicate for 747.
> >> >>> OK, I will see if I find the time to fix it. The first barrier
is to
> >> >>> get
> >> >>> acqainted with the code...
> >> >>
> >> >> Let us know how we can help!
> >> >>
> >> >> - Brett
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/logic-to-prevent-overwriting-release-artifacts-tp25564416p25749141.html
> >> Sent from the archiva-dev mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/logic-to-prevent-overwriting-release-artifacts-tp25564416p25753420.html
> Sent from the archiva-dev mailing list archive at Nabble.com.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message