Re: [VOTE] JMeter 2.3.2RC3

Sun, 01 Jun 2008 13:17:56 -0700 

sebb wrote:

On 01/06/2008, Dennis Lundberg <[EMAIL PROTECTED]> wrote:

Oleg Kalnichevski wrote:


On Sat, 2008-05-31 at 20:44 +0100, sebb wrote:


On 31/05/2008, Dennis Lundberg <[EMAIL PROTECTED]> wrote:


sebb wrote:


...



 How about adding a "download-libraries" target to the Ant build, that
downloads the dependencies from the central (Maven) repository?



That's a possibility for a future release.



Better yet, consider using Ivy [1], which is now an Ant sub-project, for
dependency management. I am sure it must be possible to get Ivy to
retrieve and copy all project dependencies to a local folder.


 Yes, either Ivy or Maven Ant Tasks [2] can be used for this.

 I'm not sure though that these can be used without actually installing the
corresponding Antlib locally. We don't want people to have to install stuff
to their Ant installation to be able to build JMeter.



Indeed.

I tried the quick Ivy sample, and that works without needing to
download anything.


Cool


But given that all the JMeter dependencies are already known, I don't
see any point in having Ivy scan all the source files, clever though
that is.
The major benefit I see with using Ivy or Maven Ant tasks is that you get your dependencies specified in a standardized documented format.
I had a look at the build.properties file for JMeter and most of the dependencies are in a format that should help you to determine which jar to use. But then there are a couple of others like: 

soap.jar                    = ${lib.dir}/soap.jar
tidy.jar                    = ${lib.dir}/Tidy.jar

that don't specify a version.
There are two sides of specifying dependencies: for developers and for users.
For users, the current setup is easy for the user, just download the binary distro and you have everything you need. That is if you are using JMeter standalone. If you want to use JMeter inside another application then you need to make sure that you include all dependencies. This first becomes a problem when you add other dependencies needed for your own application. At that point the user really wants to know which versions of the dependencies to use.
We as developers also need to keep track of the dependencies, in order to include the right ones in the distributions, but also to see whether or not it's time to upgrade a dependency. 


 The quick, but perhaps not so elegant, solution is to have a bunch of <get>
calls that fetches the jars from the central repo.


That's what I was thinking of.
The jars need to be in the lib directory or JMeter won't find them at runtime.

It's also easier when using Ant to create the binary archive.
Not necessarily. Maven Ant Tasks have ways that let you access you dependencies for either a classpath or a binary distribution, and I'm sure Ivy has something similar. This has the benefit of declaring your dependencies once and then using them later for different things. 




 [2] http://maven.apache.org/ant-tasks.html




Oleg
[1] http://ant.apache.org/ivy/



Almost all users of JMeter will need the binary version.

Anyone who wants to build add-ons for JMeter will need the binary

version.

It's only if someone wants to build JMeter from scratch that they will
need the source.

We did consider releasing JMeter as 3 archiives: source, binary and
libraries, but it was felt that the user should not be required to
download multiple archives in order to start using JMeter.



For a Maven project, this is done by declaring dependencies on the
library files, which it may (or may not if "provided") download for
you.

In this case, the Ant file has a dependency on the binary archive.

It

just does not download it for you.




      Best regards
              Henning


 sebb schrieb:





On 30/05/2008, sebb <[EMAIL PROTECTED]> wrote:




On 28/05/2008, Henri Yandell <[EMAIL PROTECTED]> wrote:
 > MD5, PGP good.
 >
 >  It's a bit odd that the binary version comes chock full of

jars

and


 >  the source version doesn't. When I run 'ant' in the source


version I


 >  get:
 >
 >  BUILD FAILED
 >



/Users/hen/apache/jmeter/jakarta-jmeter-2.3.2/build.xml:925:

 >



/Users/hen/apache/jmeter/jakarta-jmeter-2.3.2/lib/opt

not


found.



I need to look at that.




Fixed in SVN.

If a build is attempted from just the source archive the output

is:

C:\ReleaseCheck\jakarta-jmeter-test> ant
Buildfile: build.xml

_message_3rdParty:
  [echo] Cannot find all the required 3rd party libraries.
  [echo] If building from a release, you need both source and
binary archives.

BUILD FAILED


C:\ReleaseCheck\jakarta-jmeter-test\build.xml:937:

Cannot


find required classes





 >  I'm also suspect of whether it will build with so few jars



available.



 >  I don't see junit in there, or being hooked up to

download.


It won't build on its own.
 To avoid duplication, building requires the binary archive as

well.

 This is documented in the README file.


 >  In the current source download, the geronimo and velocity

jars



should



 >  ideally have their license and notice files.


As they are ASF projects, I assumed that they were covered by

the

 following in the NOTICE file:

 "This product includes software developed at
 The Apache Software Foundation (http://www.apache.org/)."

 and the LICENCE.


 >  The following jars need license files in the binary

download:

 >
 >  junit (CPL)
 >  htmllexer (I'm assuming it's under the htmlparser CPL?)


Yes, it's part of htmlparser.

 >  js_rhino (MPL iirc)
 >

 OK; there were pointers to the online versions in the main

LICENSE

 file, but I've now added local copies.


 >  Ideally, various ASF Apache 2.0 licenses/notices would

also be



there;



 >  but those are the three important ones.


Thanks.


 >  Hen
 >
 >
 >  On Tue, May 27, 2008 at 4:50 PM, sebb <[EMAIL PROTECTED]>

wrote:

 >
 > > [Third time lucky, I hope]
 >  >
 >  >  There is one trivial code change from RC1:
 >  >  * Log the property java.vm.name which shows whether the


-client


or -server



 >  >  Java flag was used when starting JMeter
 >  >
 >  >  Otherwise the main changes relate to the way the

archives are



created:



 >  >  the tar files use LF endings for native files, and the

zip

files


use



 >  >  CRLF endings. The JMX test and demo files have been

updated

to


the new



 >  >  format. Some AL headers were added.
 >  >
 >  >  As far as I can tell I've fixed all the previous test


problems


that



 >  > were reported (and one I accidentally introduced in RC2

when

the


EOL



 >  > settings were tidied up).
 >  >
 >  >  Note that there is a bug in Java on some Linux systems

that



manifests



 >  >  itself as the follow error:
 >  >
 >  >  [java] WARNING: Couldn't flush user prefs:
 >  >  java.util.prefs.BackingStoreException:
 >  >  java.lang.IllegalArgumentException:

Not



supported: indent-number



 >  >
 >  >
 >  >  Archives/hashes/sigs and RAT report:
 >  >



http://people.apache.org/~sebb/jmeter-2.3.2RC3/dist



 >  >
 >  >  Site/Docs are here:
 >  >



http://people.apache.org/~sebb/jmeter-2.3.2RC3/docs



 >  >
 >  >  Tag:
 >  >



http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_3_2RC3

 >  >
 >  >  Keys are here:
 >  >



http://svn.apache.org/repos/asf/jakarta/jmeter/trunk/KEYS.txt

 >  >  also
 >  >


http://www.apache.org/dist/jakarta/jmeter/KEYS


 >  >
 >  >  All feedback (and votes!) welcome.
 >  >
 >  >  [  ]+1 - the release candidate is OK
 >  >  [  ]-1 - there is a problem (please indicate what it

is)

 >  >
 >  >  The vote will remain open for at least 72 hours.
 >  >
 >  >  Note: If the vote passes, the intention is to release

the

archive


 >  >  files and create the release tag from the RC3 tag.
 >  >
 >  >  Here's my:
 >  >
 >  >  +1
 >  >
 >  > S///
 >  >
 >
 > >



---------------------------------------------------------------------

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

 >
 >







---------------------------------------------------------------------

To unsubscribe, e-mail:



[EMAIL PROTECTED]



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





 --
 Henning P. Schmiedehausen  -- [EMAIL PROTECTED] | J2EE, Linux
 91054 Buckenhof, Germany   -- +49 9131 506540  | Apache person
 Open Source Consulting, Development, Design    | Velocity -

Turbine

        "Save the cheerleader. Save the world."





---------------------------------------------------------------------

 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]





 --
 Dennis Lundberg




---------------------------------------------------------------------

 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]






---------------------------------------------------------------------

To unsubscribe, e-mail:

[EMAIL PROTECTED]

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





 --
 Dennis Lundberg

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





--
Dennis Lundberg

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

Reply via email to