----- Original Message -----
From: "Sam Ruby" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 21, 2001 8:57 PM
Subject: Re: [gump][cactus] nightlies for Cactus-23


> 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
>

hum ... that looks fine ...

> 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";
>

I'm not too strong in perl, I'll trust you on that one ... ;-)

> > 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.

yes, the file names do match but not the content, which led me to believe
they were not the correct files. As I do believe you, we need to find out
where the magic happens ...  (I wasn't sure until now how you copied the
files to the nighlty build area and what operations you did in between ...
:) ).

What troubles me is that fact, for instance, that the
http://jakarta.apache.org/builds/jakarta-cactus/nightly/2001-09-21/jakarta-c
actus-22-20010921.zip zip contains a sample/target directory. It does not
happen on my machine ... hum ... hold on ... would that be because I am not
running with the latest Ant (I'm using the released Ant 1.4) and the copy
task has changed behaviour or because the behaviour is not the same on
windows and unix ... ? I am now convinced it is an error of this type ...
I'll hunt it down ...

>
> > 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?

Sorry but I did not get any message of any failure for at least a full week
! I knew they should have been posted on jakarta-commons but nothing was
posted there ...

>
> >> 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.j
ar
>
> 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.

I have only one suggestion :
* Have all project name their jars with no version information in the name.
The version information should be put in the manifest. Names should be "<jar
name>.jar"
* Released zips should contain full name : jakarta-<project
name>-<other>.zip|gzip|tar.gz but once you unzip it, you'll find the <jar
name>.jar jars.
* I don't know why log4j changed that. They were delivering 2 files not long
ago : log4j-core.jar and log4j.jar. Now, they deliver only one :
log4j-1.2alpha.jar. I don't like it ...

>
> >> 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.

I'm now convinced ... no need for more ... :)

Thanks for your help and patience.
-Vincent




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to