You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@archiva.apache.org by Marc Lustig <ml...@marclustig.com> on 2009/10/05 13:32:35 UTC
Re: logic to prevent overwriting release-artifacts
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 (?)
> - artifact data (groupId, artifactId, ...)
>
> 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, ....)
>
> 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.
Re: logic to prevent overwriting release-artifacts
Posted by Deng Ching <oc...@apache.org>.
Hi Marc,
I think you can pattern and add your test to the ones for the
RepositoryServlet where all the webdav tests are. They're sort of an
integration test for the webdav components.
Thanks,
Deng
On Fri, Oct 9, 2009 at 2:59 PM, Marc Lustig <ml...@marclustig.com> wrote:
>
> To implement the unit-test it would be quite helpful to execute the
> unit-test
> based on a runtime-environment. Does the Archivas build-process allow to
> execute unit-tests in a runtime-environment?
> Otherwise you will have to mock all kinds of objects, which doesn't reflect
> the real scenario in the end and also is a lot of work.
> --
> View this message in context:
> http://www.nabble.com/logic-to-prevent-overwriting-release-artifacts-tp25564416p25816355.html
> Sent from the archiva-dev mailing list archive at Nabble.com.
>
>
Re: logic to prevent overwriting release-artifacts
Posted by Marc Lustig <ml...@marclustig.com>.
To implement the unit-test it would be quite helpful to execute the unit-test
based on a runtime-environment. Does the Archivas build-process allow to
execute unit-tests in a runtime-environment?
Otherwise you will have to mock all kinds of objects, which doesn't reflect
the real scenario in the end and also is a lot of work.
--
View this message in context: http://www.nabble.com/logic-to-prevent-overwriting-release-artifacts-tp25564416p25816355.html
Sent from the archiva-dev mailing list archive at Nabble.com.
Re: logic to prevent overwriting release-artifacts
Posted by Marc Lustig <ml...@marclustig.com>.
Hi all,
please find the patch here: http://jira.codehaus.org/browse/MRM-747
For us it would be important to get this integrated into the trunk asap, so
that 1.2.3 will already contain it.
Can I please ask to review the patch and let me know if something should be
changed.
thanks
Marc
Deng Ching-2 wrote:
>
> 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.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/logic-to-prevent-overwriting-release-artifacts-tp25564416p25803006.html
Sent from the archiva-dev mailing list archive at Nabble.com.
Re: logic to prevent overwriting release-artifacts
Posted by Deng Ching <oc...@apache.org>.
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.
>
>
Re: logic to prevent overwriting release-artifacts
Posted by Marc Lustig <ml...@marclustig.com>.
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.
Re: logic to prevent overwriting release-artifacts
Posted by Deng Ching <oc...@apache.org>.
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.
>
>