You are viewing a plain text version of this content. The canonical link for it is here.
Posted to regexp-user@jakarta.apache.org by "David M. Karr" <dk...@tcsi.com> on 2000/11/01 19:20:09 UTC
Small issues with jakarta-regexp distribution
Two suggestions for how the jakarta-regexp distribution should be
built/packaged:
1. Make the default javadoc build only do "public" and
"protected". There appear to be private methods described here,
which just gets in the way of understanding how to use it.
2. The name of the produced jar file should be
"jakarta-regexp.jar", not "jakarta-regexp-1.1.jar" (but still
inside of the "jakarta-regexp-1.1" directory). I don't want to
have to change my Makefiles just because I've upgraded the
version for implementation changes, and not interface changes.
3. There may have been good efficiency reasons to separate out the
compiler class so it has to be run from the command line, but it
might be worthwhile to provide a convenient API so that
programmers can precompile REs, without having to run a
command-line script.
4. And finally, provide a binary release in addition to the source
release.
--
===============================================================================
David M. Karr ; dkarr@tcsi.com ; w:(425)487-8312 ; TCSI & Best Consulting
Software Engineer ; Unix/Java/C++/X ; BrainBench CJ12P (#12004)
Re: Small issues with jakarta-regexp distribution
Posted by "David M. Karr" <dk...@tcsi.com>.
>>>>> "Jon" == Jon Stevens <jo...@latchkey.com> writes:
Jon> on 11/1/2000 10:20 AM, "David M. Karr" <dk...@tcsi.com> wrote:
>> Two suggestions for how the jakarta-regexp distribution should be
>> built/packaged:
>>
>> 1. Make the default javadoc build only do "public" and
>> "protected". There appear to be private methods described here,
>> which just gets in the way of understanding how to use it.
Jon> cd build
Jon> vi build-regexp.xml <-- remove the stuff that turns private on
Jon> ./build-regexp javadocs
>> 2. The name of the produced jar file should be
>> "jakarta-regexp.jar", not "jakarta-regexp-1.1.jar" (but still
>> inside of the "jakarta-regexp-1.1" directory). I don't want to
>> have to change my Makefiles just because I've upgraded the
>> version for implementation changes, and not interface changes.
Jon> ln -s jakarta-regexp-1.1.jar jakarta-regexp.jar
>> 3. There may have been good efficiency reasons to separate out the
>> compiler class so it has to be run from the command line, but it
>> might be worthwhile to provide a convenient API so that
>> programmers can precompile REs, without having to run a
>> command-line script.
Jon> Submit a patch.
All spoken from the point of view of a developer who wants more help
to do his job :) .
>> 4. And finally, provide a binary release in addition to the source
>> release.
Jon> Huh? It comes with a .jar.
The only distribution I found was a source release, which requires
building it in order to obtain the jar with the class files.
--
===============================================================================
David M. Karr ; dkarr@tcsi.com ; w:(425)487-8312 ; TCSI & Best Consulting
Software Engineer ; Unix/Java/C++/X ; BrainBench CJ12P (#12004)
Re: Small issues with jakarta-regexp distribution
Posted by Jon Stevens <jo...@latchkey.com>.
on 11/1/2000 10:20 AM, "David M. Karr" <dk...@tcsi.com> wrote:
> Two suggestions for how the jakarta-regexp distribution should be
> built/packaged:
>
> 1. Make the default javadoc build only do "public" and
> "protected". There appear to be private methods described here,
> which just gets in the way of understanding how to use it.
cd build
vi build-regexp.xml <-- remove the stuff that turns private on
./build-regexp javadocs
> 2. The name of the produced jar file should be
> "jakarta-regexp.jar", not "jakarta-regexp-1.1.jar" (but still
> inside of the "jakarta-regexp-1.1" directory). I don't want to
> have to change my Makefiles just because I've upgraded the
> version for implementation changes, and not interface changes.
ln -s jakarta-regexp-1.1.jar jakarta-regexp.jar
> 3. There may have been good efficiency reasons to separate out the
> compiler class so it has to be run from the command line, but it
> might be worthwhile to provide a convenient API so that
> programmers can precompile REs, without having to run a
> command-line script.
Submit a patch.
> 4. And finally, provide a binary release in addition to the source
> release.
Huh? It comes with a .jar.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/