On Jan 6, 2008 4:46 AM, simon <[EMAIL PROTECTED]> wrote: > But the problem is that the files published are only a *partial* release > (myfaces-project and myfaces-impl, but not myfaces-build or > myfaces-api). All the artifacts need to go out together to form a valid > release AFAIK. I'm not sure what effect this will have on users, but it > doesn't seem like a good idea to leave them there.. > > The fact that they were released too early is a mistake. The fact that > only a partial release happened is due to bad file permissions on the > myfaces-build directory, making it unwritable except for the owner. I've > emailed the current owner of that dir asking for g+w to be added.
Agreed. I just wasn't comfortable asking root to remove the files, (since the vote *did* pass) and suggested waiting for the file owner. > The bad dirs have now been removed from people.apache.org. However the > maven release process actually *overwrites* the metadata files in the > parent dir, and we have no copies of the old files AFAIK. So if we do > get the bad dirs removed from repo1.maven.org and mirrors, does this fix > the problem or will the bad metadata files still stuff users up? Bad metadata for a released jar artifact (as opposed to a snapshot or a plugin) isn't going to cause too much of a problem. If someone is trying to use version ranges, it might. But if you declare a dependency on a specific version, Maven just constructs the url and grabs the file, without checking the metadata. Maven isn't overwriting the metadata, we are. :) But only because the tool that properly merges a new release into an existing repository (updating the metadata rather than overwriting it) hasn't emerged from the sandbox yet. It's maven-stage-plugin, and it's already being used for Maven project releases. So the MyFaces metadata has been technically wrong for a long time, though it's usually just missing old releases, rather than mentioning one that does not exist as it does now. Or, did. I edited the maven-metadata.xml files to say "1.2.0" instead of "1.2.1" just now, and posted to [EMAIL PROTECTED] asking for the 1.2.1 files to be removed from central. > I guess the other solution is to just do nothing until the *real* 1.2.1 > release goes out, overwriting the bad files. I believe that is expected > to happen in the next week or so. But I feel a little uncomfortable > about that, and at the least we would need to notify the user list. IMO there should not be a "real" 1.2.1 release now -- we should move on to 1.2.2 to avoid confusion in case anyone has downloaded these bad jars. In general I'm not opposed to a "do-over" if the RM quickly deletes a tag and tries again, but the longer a set of files has been available, the greater chance of having to deal with "well, _which_ 1.2.1 jars do you have?" type support questions. -- Wendy
