JMeter site

[Jordi Salvat i Alabart <js...@atg.com>]

Hi.

As you may be aware of, I broke the way the JMeter site used to be 
published :-(

I still believe the approach of keeping in CVS only things that can't be 
obtained from source is cleaner, and better in the long term; but I need 
to reinstate a practical way to publish the docs.

Possible ways:
a/ Undo my change and add back the generated docs to CVS
b/ Have the nightly build republish the docs every day
c/ Have the nightly build create a docs distribution, which someone 
would need to pull and publish (just as we did when they were in CVS).
d/ ¿Other ideas?

a/ Has three problems:
1/ As said, needs "redundant" stuff to be kept in CVS. I don't like this 
-- although I admit it's a matter of taste.
2/ Requires developers to check-in produced docs in addition to the 
source xdocs whenever they make a change. Not a big deal, but it's easy 
to forget and may cause conflicts from time to time
3/ It's difficult to verify the content before publishing

b/ is great because it keeps things up-to-date and requires no 
invervention, but of course we may occasionally find our site totally 
broken.

c/ looks great, but I'm not sure how confortable it will be for whoever 
has to do the work -- and we'll make him responsible for the checking, 
which is probably unfair.

Anyone can think of a d/ or an e/? Arguments for or against each of the 
aproaches?

FYI, most --but not all-- jakarta projects use a/. I don't know exactly 
what the others (e.g. jakarta-oro) do.

Salut,

Jordi.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

JUnit in binary dist.

[Jordi Salvat i Alabart <js...@atg.com>]

Mike wrote:
> I'm also wary of pulling JUnit from the distribution.  How sure are you this won't be 
> a problem?  Have you tested all of JMeter's functionality without it?

I've been thinking about this. You're right: as we discussed a while 
ago, we want to have the unit tests in the product's .java files -- this 
means JUnit needs to be there at compile-time, and of course at 
test-time. It would be a severe informality not to have them around at 
run-time, even if they're never used (you'll never know).

I'll reinstate the Gump and build.xml entries for that .jar.

Salut,

Jordi.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: JMeter site

[Jordi Salvat i Alabart <js...@atg.com>]

 > Do you all have accounts on jakarta.apache.org?

I don't, AFAIK. I asked root@apache.org to get one, but got no answer.

> Having the docs in CVS makes it convenient, because all you need to do is log in 
> to jakarta.apache.org, cd to the right directory, and type "cvs update -d", and 
> you're done publishing the docs.  I would not want to have to scp a tarball and 
> unzip it there - that's a pain.  It's bad enough I have to do that to make a release.  If 
> I had to do that everytime I updated the web site, it wouldn't get updated very often.

With the proper setup, it can be a 1-word command -- and actually 
quicker than a cvs co... I'd take care of scripting it if we finally 
chose this option.

> I don't see a problem with the docs in CVS.  But then, I use WinCVS, which is 
> very handy and quicker than using command-line cvs.  I could hardly "miss" or 
> forget to update the docs, because WinCVS makes it obvious when I have 
> modified files that I haven't checked in.  

Me too with lincvs, but what about people using command line (is there 
any?).

 > I'm also wary of pulling JUnit from the distribution.  How sure are 
you this won't be
 > a problem?  Have you tested all of JMeter's functionality without it?

No, I haven't. Anyway, JUnit is still there for the time being -- just 
not the one used by Gump for the compile, but the one we have on CVS. 
It's a long story... to make it short: these Gump nightly builds are 
strange creatures: they are built from the latest code from CVS for each 
package. I need to replace the .jars in jakarta-jmeter/lib to ensure 
they run with the same versions they were compiled with.

Do you think it's any likely that it will break anything? Doesn't look 
like to me... should be used only at test-time, shouldn't it?

Salut,

Jordi.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: JMeter site

[Mike Stover <ms...@apache.org>]

Publishing the docs nightly, from my experience, would be a bad idea.  We don't 
see the problem now, when we're just tweaking things here and there.  The problem 
comes in when you're getting ready to release JMeter 1.9 - then, wholesale 
changes will be needed, by multiple people, over a period of a couple weeks most 
likely.  If an automatic process is publishing the site at that point, it won't work.

Do you all have accounts on jakarta.apache.org?  You should check it out.  I 
usually ssh to cvs.apache.org, and then ssh to jakarta.apache.org from there.  
Make sure you can do that - if you can't, we need to get your account set up over 
there.  

Having the docs in CVS makes it convenient, because all you need to do is log in 
to jakarta.apache.org, cd to the right directory, and type "cvs update -d", and 
you're done publishing the docs.  I would not want to have to scp a tarball and 
unzip it there - that's a pain.  It's bad enough I have to do that to make a release.  If 
I had to do that everytime I updated the web site, it wouldn't get updated very often.

I don't see a problem with the docs in CVS.  But then, I use WinCVS, which is 
very handy and quicker than using command-line cvs.  I could hardly "miss" or 
forget to update the docs, because WinCVS makes it obvious when I have 
modified files that I haven't checked in.  

I'm also wary of pulling JUnit from the distribution.  How sure are you this won't be 
a problem?  Have you tested all of JMeter's functionality without it?

-Mike

On 10 Jan 2003 at 19:12, Jordi Salvat i Alabart wrote:

> Hi.
> 
> As you may be aware of, I broke the way the JMeter site used to be 
> published :-(
> 
> I still believe the approach of keeping in CVS only things that can't be 
> obtained from source is cleaner, and better in the long term; but I need 
> to reinstate a practical way to publish the docs.
> 
> Possible ways:
> a/ Undo my change and add back the generated docs to CVS
> b/ Have the nightly build republish the docs every day
> c/ Have the nightly build create a docs distribution, which someone 
> would need to pull and publish (just as we did when they were in CVS).
> d/ ¿Other ideas?
> 
> a/ Has three problems:
> 1/ As said, needs "redundant" stuff to be kept in CVS. I don't like this 
> -- although I admit it's a matter of taste.
> 2/ Requires developers to check-in produced docs in addition to the 
> source xdocs whenever they make a change. Not a big deal, but it's easy 
> to forget and may cause conflicts from time to time
> 3/ It's difficult to verify the content before publishing
> 
> b/ is great because it keeps things up-to-date and requires no 
> invervention, but of course we may occasionally find our site totally 
> broken.
> 
> c/ looks great, but I'm not sure how confortable it will be for whoever 
> has to do the work -- and we'll make him responsible for the checking, 
> which is probably unfair.
> 
> Anyone can think of a d/ or an e/? Arguments for or against each of the 
> aproaches?
> 
> FYI, most --but not all-- jakarta projects use a/. I don't know exactly 
> what the others (e.g. jakarta-oro) do.
> 
> Salut,
> 
> Jordi.
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 



--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>