You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by Berin Loritsch <bl...@apache.org> on 2002/05/01 16:38:34 UTC

Re: Iaik classes

Stover, Michael wrote:
> URLClassLoader!  I wish I'd heard about that before.  I agree wholeheartedly
> this is better than scooping up jars in a batch file to add to the
> classpath.
> 
> I'll look at the Excalibur CLI stuff at some point.  I'll probably work on
> this revamping of build/install/run when I'm ready to ditch the current src
> and transfer to the src_1 branch.
> 
> I doubt JMeter is in need of a build system more capable than Ant, but it
> could be more organized.  The /classes directory is just a temporary resting
> area that should perhaps be deleted afterwards (though this would slow up
> developers).   This can easily be worked out though.
> 
> The module thing is something we've been talking about forever but not
> actually done.  Such a structure would make it easier to exclude certain
> files from a project.  But, I would need you to specify which files would
> make up an "Iaik" module.  I'll get back to you on this when I've made the
> structure you propose.

Cool.  And we should keep these discussions on the developer's list--it
does pertain to the list and it helps keeping other developers appraised
about what is going on.  (I am an advocate of open communication :)

> 
> -Mike
> 
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Wednesday, May 01, 2002 10:09 AM
> To: Stover, Michael
> Subject: Re: Iaik classes
> 
> 
> Stover, Michael wrote:
> 
>>Berin,
>>      I'm wondering if you can do anything about the Iaik classes in
> 
> JMeter.
> 
>>Although Ant can deal with compiling around them, most IDE's can't when
>>doing internal compiles.  I get stuck always getting errors from these
> 
> files
> 
>>whenever I compile anything.  Is there anything we can do to change this?
>>
>>Also, I don't see what good it does anyone to have a binary release where
>>none of these files are ever compiled, and thus won't work anyway unless
> 
> the
> 
>>user compiles them.  There might be a better place for these files to live
>>other than the JMeter project.
>>
>>Thoughts?
> 
> 
> 
> We need to look at the build process for JMeter anyway.  It's not very
> elegant.  However, that said, I do have some ideas.
> 
> 1) Adopt an unofficial standard for the src directory:
>      ${jmeter.home}/src
>                       /java
>                       /test
>                       /${module}
>                       /proposal
>                       /xdocs
> 
>      That way, we can move the iaik files into a subdirectory of src/
>      keeping them separate from the core build.  We can have IAIK support
>      as an optional build, or as a separate jar.  Either way is fine by
>      me.
> 
> 2) Better classloader magic:
>      If we have an official directory for extensions to JMeter, it can
>      make it easier for third parties to add extensions without breaking
>      JMeter.  We would use a URLClassLoader and load all the jars in a
>      directory into the classloader.  This enables the separate IAIK
>      support jar.
> 
> 3) Using Avalon Excalibur's CLI package:
>      It can be used independantly of anything--and it is better to
>      programatically manage our options and our option syntax than to
>      rely on the convenience scripts to do it for us.
> 
> 4) Better build system:
>      Maven, Krysalis, or just a better ANT build would help.  Currently,
>      JMeter mixes the install /classes directory and the install.  That
>      is confusing.  Jmeter should be its own jar with a Main-Class
>      entry in its manifest.  We should have a better definition of an
>      install, and a directory structure.
> 
> 



-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


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