What Wendy said :)
- we should roll back the commit, I don't think it's a good idea in
general (and IIUC, it doesn't apply the changes for the pre-
configured repos at all)
- if we agree to pre-configure the repos, we need to seek a simpler
solution.
Joakim - I'm a little confused about the purpose of your mail -
everything screamed that you thought the solution was a bad idea and
then you suggested you might go ahead with it :) Just saying, it was
a bit hard to grok what exactly you were getting at doing. (There are
also reasons the math about how many components.xml would be touched
and what might get dragged in to test it that weren't quite right,
but it's a non-issue if the solution is different - it was more
related to the fact that dragging all that stuff into configuration
was clearly a bad idea).
Off the top of my head, I would think we should assign the
permissions in the current code that checks for existence of roles on
startup, and only when the roles did not previously exist. This will
only get hit for the pre-configured repos - those added later will
create the roles themselves and not configure any permissions. It
should check the ID name against the default ones so it doesn't
automatically assign to all those pre-configured by hand. If you are
not content that is robust enough, I'd be happy with a flag
<preconfigureGuestAccess>true|false</preconfigureGuestAccess> in the
repository configuration that can be added to default-archiva.xml but
is false by default.
Is that a better way to go?
Cheers,
Brett
On 13/10/2007, at 10:43 PM, Wendy Smoak wrote:
On 10/12/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
I can only think of 1 place for this.
When DefaultArchivaConfiguration loads the default-archiva.xml
from its
resources location and puts it into place.
That makes sense on a high level, but there's rarely only one way to
do something. Before we go further with this I'd like to see more
discussion around the 'pre-configure guest access' feature.
For now, do we all agree that this commit wasn't what was intended by
MRM-398 and should be reverted?
That should be a 4 part commit (once split by apache's commit message
email split routines)
And that's the bare minimum work.
It's likely that archiva-security goes away, and archiva-
configuration
gains a bunch of security.
Ready for it?
Once again, it's not necessarily length, it's complexity (unrelated
changes) and the amount of communication around the change.
For example, I raised a concern about this commit, which fit nicely
into one message, because I don't think it's what we 'agreed on' by
opening and scheduling the issue.
--
Wendy
--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/
