[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: java-getopt
"Raif S. Naffah" wrote:
> i'll finish the getopt stuff since i started it. but i need some
> decisions. provided java-getopt classes are not embedded in the sablecc.jar:
>
> 1. the getopt package comes all in one piece. i can separate the source
> from the .class + other needed files to build a pure .jar file that gets
> used by sablecc. the alternative would be to use it as is. in both cases
> the manifest will be written to expect the java-getopt.jar to be at the
> same level as the sablecc.jar. (to me it makes more sense to keep it as is)
Personally I like sources to be in *-src.tar.gz files. I prefer to keep
the
".jar" packaging solely for "executable jar files" (or jars meant to be
put
on the classpath). One can always use .zip otherwise.
Don't worry too much about packaging. Instead, it would be nice if you
put
your efforts into writing the correct Manifest files so that one could
put sablecc.jar, sablecc-ant.jar, and getopt.jar in a single directory
then write "java -jar sablecc.jar" to run the whole thing [no classpath
settings, or any other setting required].
> 2. renaming java-getop-xxx.jar to just java-getopt.jar (doing that in ant's
> build.xml is trivial) would protect against future versions of java-getopt,
> that are feature-compatible with those used by sablecc, from requiring a
> re-packing/change to the sablecc distribution. any objection to following
> this scheme?
This is OK for the "executable jar". I like the distribution packages
to have
an explicit version. It is OK for now (until something like "RAK" comes
out)
to hard code a build dependency between SableCC x1.y1.z1 and getopt
x2.y2.z2.
Would you like CVS write access? It would lessen the pressure on
Mariusz and
me a little... ;-)
Thanks a lot.
Etienne
--
Etienne M. Gagnon egagnon@j-meg.com
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/