Vincent Massol wrote:
>
>> At the moment, I copy everything that is in
>> jakarta-cactus/dist/jakarta-cactus* to
>> /www/jakarta.apache.org/builds/jakarta-cactus/nightly .
>
>I guess you mean jakarta-cactus/dist/cactus-* (where * = 22 or 23) ?
You are correct. More precisely, I do the following on rubix (ignoring all
non-cactus related copying):
rm -rf pub
mkdir pub
cd pub
cp ../jakarta-cactus/dist/jakarta-cactus* .
scp * [EMAIL PROTECTED]:/home/rubys/staging
On daedalus:
sub post($$) { ($source, $dest) = @_;
@files = glob("/home/rubys/staging/$source*");
if (@files) {
################################################################
# Clean up old builds
################################################################
chdir "/www/$dest";
rmtree $date, 1, 1 if -d $date;
$count=0;
foreach (reverse sort <20??-*>) {
next if $count++<6;
rmtree $_, 1, 1;
}
################################################################
# Copy files from the staging area
################################################################
print "/www/$dest/$date\n";
mkdir "/www/$dest/$date", 0775;
chdir "/www/$dest/$date";
foreach (@files) {
copy $_, ".";
unlink $_;
}
}
};
post "jakarta-cactus", "jakarta.apache.org/builds/jakarta-cactus/nightly";
> However, I don't think this is true seen the result for the 21/08 for
> example. For the following reasons :
> - In jakarta-cactus/dist/cactus-*, there are no zip file but in
> /www/jakarta.apache.org/builds/jakarta-cactus/nightly/2001-09-21 you find a
> zip named jakarta-cactus-22-20010921.zip. Maybe you do a zip a everything in
> jakarta-cactus/dist/cactus-* before copying ?
> - In jakarta-cactus-22-20010921.zip, you'll find a target directory but none
> exist in jakarta-cactus/dist/cactus-* (as no build is done in the dist
> directory)
> - some other reasons.
The only operations I am doing are copy operations. The files that I see
on the web site match those that were apparently produced as a result of
the build.
> Now, what I would really like to be copied in
> /www/jakarta.apache.org/builds/jakarta-cactus/nightly are the following
> files that are generated by the Cactus build process (dist.gump target) :
>
> - jakarta-cactus/dist/jakarta-cactus-22-20010921.zip
> - jakarta-cactus/dist/jakarta-cactus-23-20010921.zip
> - jakarta-cactus/dist/jakarta-cactus-src-20010921.zip
It is my belief that these are the files that I post.
>> This
>> being said (1) if I don't build it, then I can't upload it;
>
>I've never asked for this, have I ? If I have, then dismiss it as this is
>not my intent.
I guess what confused me is that you are asking me to post cactus-23 builds
- despite getting daily "nags" for the last few days that cactus-23 builds
have been failing. You want me to post what I do not have?
>> In
>> order to have predictable jar names, I have inserted version="gump"
>> properties on various projects
>>
>> I'm not sure I understand why you do this ? What do you think about the
>> issues I have raised on the subject of naming the generated jars
>> xxx-gump.jar ?
Perhaps an example would help. As you know, I construct the classpath
prior to invoking ant. For jakarta-cactus-23, this includes:
export
CLASSPATH=$CLASSPATH:/home/rubys/jakarta/jakarta-log4j/dist/lib/log4j-gump.jar
Once upon a time, I did not override the version parameter. That would
mean that the jars produced would have been named log4j-1.2alpha. As this
goes from alpha, to beta, to release, to the development version for future
releases, the names of the jars would change, the builds would fail, and I
would have to update the project definitions. A given project may only
change status once a month or so - but multiply that by the number of
projects that I am tracking, and you have a lot of work.
That's why I believe I need predictable jar names. I welcome suggestions.
>> Finally, I do believe that the actual files I posted for cactus are the
>> results of the build process for cactus, and totally under the control of
>> the build.xml.
>
>For the reasons mentionned above, I don't think they are the files generated
>by the dist.gump target.
I'm not sure how else to convince you.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
