myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wendy Smoak" <>
Subject Re: partial set of core-1.2.1 artifacts published on 22 dec
Date Sun, 06 Jan 2008 15:55:15 GMT
On Jan 6, 2008 4:46 AM, simon <> 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 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 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 repository@a.o 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

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.


View raw message