Hey Guys,
Ok, I did the research on this. First issue was with the src
distribution archive. This archive was correct in the 1.0.8
distribution. The src archives are the same as what you see in the svn
repository. Many of the component files are generated, and therefore
don't show up in the src archive. I think you should look at the
sources in "dist" archive if you want to see the generated files as well.
As for the dist, the tar.gz does work, it's just the zip version that
got corrupted. I've regenerated the zips and can either deploy those
or, if people feel real strongly, I can take the tar.gz file and make a
zip out of it. I don't care either way, but I did a comparison of the
newly generated zip directory compared to the old tar.gz directory and
with the exception of the dates, they look the same. Let me know if you
have a preference.
If you want to see the newly generated archives, you can check them out
on my share -
http://people.apache.org/~sobryan/trinidad/1.0.8/
Scott
Scott O'Bryan wrote:
I suppose if it makes you feel better, I can manually reconstruct the
dist package based on the deployed maven artifacts in the release, but
like I say, when I generated the review artifacts in the first place,
it was essentially a faux-release taken directly from the tag.
Scott
Scott O'Bryan wrote:
Simon,
I think the screw up was on my end. Let me try to explain. Once the
release passed, I messed up the copy over to the repositories for the
dist artifacts, so I took the copies that I had built locally and
uploaded them. This upload is what failed. I should have checked
the upload better. The artifacts on my local machine have been deleted.
That said, the tag needs to be able to re-generate the artifacts.
It's integral to the release process because, when the release is
finally performed by maven, it is a clean copy of the tag which is
built and deployed to the staging directories, not the artifacts
built for the vote. I know in the case of 1.0.8 and 1.2.8 the tag
will regenerate the artifacts as they are supposed to be because when
I build those artifacts in the first place, I used a clean tag. The
binaries are simply zips of these artifacts and must be manually
generated using maven.
Scott
[EMAIL PROTECTED] wrote:
Hi Scott,
[redirecting from users to dev list]
Sorry but I don't understand why regeneration of these files is needed,
or how a corrupt file occurred at all.
The release candidate ".tar.gz" and ".zip" files were placed under
someone's home directory on people.apache.org for review right? And if
the release vote passed, then presumably people *had* tested that they
were ok. If a release vote had passed without anyone detecting that a
.zip file was truncated then there is something seriously wrong with
the
release checking process....
And after the release vote passed, the release candidate jars were
copied from someone's home directory to the distribution directory,
from
where they get replicated to the mirrors, yes?
So firstly, I don't understand how they could get corrupted with just a
local copy from one dir of people.apache.org to another.
And secondly, why can't that approved (and uncorrupt) release candidate
zip file just be used rather than regenerating from the tag? Have the
release candidate files already been deleted from their review place on
people.apache.org?
Regards,
Simon
Scott O'Bryan schrieb:
Simon, they are, and thats where I pull them from. But we had an
issue blocking the release at one point and I had to regenerate
them. It looks like the trasfer failed in my staging directory.
The maven artifacts are fine, it's just the distributables and only in
1.0.8.
Scott
On May 27, 2008, at 6:55 AM, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
Hi Scott,
Are the original artifacts still available at the location they were
published for release candidate review?
If so, it would be nicer to just use those rather than regenerate the
zip.
But I suppose as long as the unpacked zip contents match the unpacked
tar.gz contents that is a reasonable check that the rebuild worked
ok.
Probably best followed up on the dev list..
Regards,
Simon
Scott O'Bryan schrieb:
Ok, apparently something must have happened in the transfer. Let me
regenerate the artifacts from the tag.
On May 27, 2008, at 1:20 AM, Renzo Tomaselli
<[EMAIL PROTECTED]> wrote:
Scott, even more: file trinidad-1.0.8-dist.zip appears truncated
and
invalid (just 3.3 MB), while trinidad-1.0.8-dist.tar.gz is ok
(10 MB).
I tried to download from several mirrors, same result.
-- Renzo
Scott O'Bryan wrote:
Really! That's wired. Let me take a look at it tomorrow and I'll
regenerate the jars if I need to.
On May 26, 2008, at 12:20 PM, Renzo Tomaselli
<[EMAIL PROTECTED]> wrote:
Hi, just upgraded from 1.07 to 1.08. The source jar
trinidad-1.0.8-src-all.zip appear to miss quite a number of
files.
I was looking for org.apache.myfaces.trinidad.component.UIXTable,
but that folder contains a reduced number of entries as
compared to
the jar.
-- Renzo
