I agree that src_dist should just include the source files, and not any external jars, 
and should ideally only include the xml docs,
not the generated html ones.

Building JMeter would obviously require the run-time jars, but these would be needed 
for the binary distribution as well - I don't
see any point in including them in both source and binary distributions.

It may be worth splitting the binary distribution into two:
- the external jars
- the rest of the existing binary distribution. [Perhaps remove the HTML files from 
docs, and keep just the printable_docs
versions?]

As to including Ant in the distribution, I agree with Jeremy that it should not be 
included.
It seems to me that developers are likely to have this installed anyway, and Ant is 
surely now stable enough that any recent version
will build JMeter.

As far as I can tell, the only other external dependency is Anakia (Velocity), which 
is needed to create the documentation.
This could perhaps be included in the source distribution, but I think it would be 
better just to leave up to developers to download
it separately. As with Ant, they might already have it. The build.xml file can be 
updated to allow anakia to be picked up from lib/
and/or ../jakarta-site2/.

Which reminds me: I would like to propose some enhancements to build.xml:

- allow the source/binary distributions to be created without rebuilding everything. 
This can be done by introducing two new targets
which just do the tar/[g]zip etc. These targets could be marked "internal", i.e. no 
description.
E.g. Make "dist" depend on "dist_tar", and move the tar/gzip/zip to dist_tar. 
Similarly for src_dist.
[The original dist and src_dist targets would still do the same work, but refactored.]

- similarly, add a target (test_only ?) that can be used to test JMeter without 
needing to do a full build.
At present, this means one cannot test a binary JMeter distribution.
[One would need to include build.xml and bin/testfiles in binary distributions.]

- be able to use build.xml without needing build.sh or build.bat (e.g. use "ant 
[target]" or Eclipse)
As it stands, build.bat does not agree with build.sh on where to look for libraries.
Also, some of the classpath information is in build.xml and some is in build.xxx, 
which is not ideal.

This means updating some classpath definitions, and adding a classpath for Anakia. 
I've got this working on Windows XP.
I've not yet had a chance to try this on Unix, but when I do, I can post a patch to 
Buzilla - unless there are any
objections/further suggestions?

Sebastian
----- Original Message ----- 
From: <[EMAIL PROTECTED]>
To: "JMeter Developers List" <[EMAIL PROTECTED]>
Sent: Sunday, August 10, 2003 2:47 PM
Subject: Re: Source dist build


Thanks to both Jeremy and Jordi for finding and fixing these problems.  I also
fixed the lack of jdom.jar in the release.  The src files are out there, however,
wouldn't it be preferable for the src dist to be a mirror of the files as they
appear in CVS?  As it is now, someone can download the src, and they're
really only half done in terms of getting everything they need to compile
JMeter.  Plus the fact that the versions of libs they choose to download might
differ from the versions that 1.9 uses, that seems like a potential problem.

I'm thinking src_dist should simply tar up all the cvs files as is and be done.
What do you all think?

-Mike

On 10 Aug 2003 at 2:49, Jordi Salvat i Alabart wrote:

> Thanks Jeremy. It worked after initializing the variables.
>
> Unfortunately, solving this implies changes to the binary dist (although
> only in unit test code).
>
> Mike: I'll check in the change -- for you to decide which release to
> include it in.
>
> -- 
> Salut,
>
> Jordi.
>
> Jeremy Arnold wrote:
> > Jordi,
> >    I took a quick look at the test failure log.  I suspect that you are
> > correct that the problem is that the tests are executed in a different
> > order.  PackageTest apparently assumes that the variables are already
> > set.  I haven't tried to check what order the tests are executed in with
> > the binary distribution, but I see that there are at least a couple of
> > tests (org.apache.jmeter.engine.util.ValueReplacer.Test,
> > org.apache.jmeter.extractor.RegexExtracter.Test) which initialize the
> > variables, and a couple other places in the JMeter code that initialize
> > them.  The best way to fix this is probably for PackageTest to
> > initialize the variables itself.  That way the tests can run in any
> > order without problems.
> >
> >    Regarding the missing lib/ant*.jar and other missing libraries:
> > isn't part of the point of having a source distribution that it doesn't
> > have all the extra binaries, so you have to either already have them or
> > download them separately?  I just checked the source distributions for
> > Tomcat and Commons-HttpClient and neither includes Ant -- they just
have
> > a BUILDING.txt that describes what you need to build it.
> >
> >    I agree that we should consider Maven for 1.10 -- a couple months ago
> > I played with building JMeter with Maven, and it seemed to work pretty
> > well, especially since we're building multiple jar files.
> >
> > Jeremy
> >
> >
> > Jordi Salvat i Alabart wrote:
> >
> >> Hi Mike. Hi everyone.
> >>
> >> "./build.sh src_dist" has some problems (in addition to the one I
> >> described in my previous message). Enumerating them here for
discussion:
> >>
> >> - The src distribution needs to be unpacked on top of the binary
> >> distribution -- otherwise the libraries in lib/ will be missing. Do you
> >> think they should be in both packages?
> >>
> >> - log4j.conf is missing form bin/. This doesn't seem to break any tests
> >> -- are they needed?
> >>
> >> - bin/testfiles/ is missing -- this is required for tests to work.
> >>
> >> - lib/ant-...jar and lib/ant-...-optional.jar are missing. They
> >> should be in the source package.
> >>
> >> - build.sh lacks the necessary execute permissions. I should add these.
> >>
> >> - There's no way to build binary and source distributions in a single
> >> shot -- you need to build one, extract the results, then build the
> >> other. I should fix this.
> >>
> >> I can fix all these without need to re-issue the binary distribution.
> >> Or we can generate a source distribution by hand (by packing up the
> >> checked-out CVS content) and sort these out later: for 1.9.1 if Mike
> >> decides to issue it for the Japanese stuff, or for 1.10. It's also
> >> possible that we need to issue a 1.9.1 anyway to sort out the unit
> >> test problem from my previous e-mail. Your opinion welcome.
> >>
> >> For 1.10, we could try to move to Maven for building. Seems to be
> >> pretty much the standard chez Jakarta. Anyone has experience with it?
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -- 
> Salut,
>
> Jordi.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>




--
Michael Stover
[EMAIL PROTECTED]
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777

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



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

Reply via email to