archive/chris-hubick/mbox

   1 From mike  Tue Aug 23 09:00:42 2005
   2 MIME-Version: 1.0
   3 Envelope-to: mike@indexdata.com
   4 Delivery-date: Mon, 22 Aug 2005 23:17:55 +0200
   5 Date: Mon, 22 Aug 2005 15:17:48 -0600
   6 From: Chris Hubick <chrish@athabascau.ca>
   7 Subject: CQL Java Distribution.
   8 To: Mike Taylor <mike@miketaylor.org.uk>
   9 Cc: mike@indexdata.com, mike@z3950.org
  10 Organization: Athabasca University
  11 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on bagel.indexdata.dk
  12 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
  13         version=3.0.0
  14 X-Spam-Level:
  15 X-StripMime: Non-text section removed by stripmime
  16 Content-type: text/plain
  17
  18 Hi.
  19
  20 First off, I have been using your CQL Java parser in my Metadata
  21 Repository software for a few years now, and it's great!  Much Thanks!
  22
  23 Second, sorry for CC spamming all the email addy's for you, I have no
  24 idea which still works and you use for this type of thing.
  25
  26 Recently, we are moving our software into a production environment,
  27 which means, as per our internal policy, I need to create RPM's for all
  28 software involved (we use RedHat Enterprise Linux).  So, as part of this
  29 effort, I sat down to create an RPM for CQL-Java.  I *could* create an
  30 RPM spec file to just package up the lib/cql-java.jar file, but as part
  31 of good practice creating RPM's, the software should ideally be compiled
  32 from it's source into source and binary RPM's.  This led to a number of
  33 problems, and my eventual overhaul of your project structure.  Attached
  34 is a zip file which, compared to the original distribution, does the
  35 following:
  36
  37 - Move from tar.gz to .zip for easier access on Windows.
  38 - Remove all binary and generated content from the distribution.
  39 - Refactor project directory structure to follow the more
  40 straightforward Maven 2 conventions:
  41 http://maven.apache.org/reference/conventions.html
  42 There is only one dir in the root of the source distribution, 'src', and
  43 ALL content is generated into subdirs of 'target'.  The src dir is
  44 further subdivided into 'main' and 'test', which are further divided by
  45 file type (java, resources, scripts), as per Maven guidelines (these are
  46 great, and are the future - more projects using them every day).
  47 - Remove all Makefiles!  Make is dead, everyone, and every IDE, uses Ant
  48 (http://ant.apache.org/) for building Java...
  49 - Include an Ant build.xml file.  This should make it possible to build
  50 on Windows or Unix, etc.
  51 - Rename documentation file base-name's to closer model GNU standards:
  52 http://www.gnu.org/prep/standards/html_node/Releases.html
  53 - Add extensions to ALL files in the distribution.  Make all shell
  54 scripts end in .sh, and Perl scripts in .pl.  Text files as .txt.
  55 - Rename all scripts to use lowercase unix naming, and prefix with
  56 cql-java, to avoid conflicts when installed in global system dirs
  57 (/bin).
  58 - Move to standard X.Y.Z-R three digit version-release versioning, to be
  59 more inline with every other package in the world.
  60 - Include a specfile to build RPMs.  This uses requirements and
  61 standards laid out by JPackage.org:  http://www.jpackage.org/ - which
  62 will be required by the RPM.  You get three RPM's, cql-java,
  63 cql-java-javadoc, and cql-java-scripts - which install to all the
  64 standard JPackage and Filesystem Hierarchy Standard locations.
  65 - Rewrite Parser/Lexer/Generator scripts to use JPackage utils and
  66 conventions.  (should work on multiple distros, using multiple Java
  67 VM's, and follow global installation guidelines now, etc).
  68 - Modify source code to fix many trivial Eclipse compiler warnings about
  69 non-static variable references and unused imports.
  70 - Include .cvsignore file to ignore Eclipse projects files and the
  71 target dir.
  72
  73
  74 Problems:
  75 - I only use the Parser Java classes in my code, and never mess with any
  76 of the test infrastructure code/scripts.  The test files were all
  77 renamed and put in better Maven'ized places, but this broke it all in a
  78 big BIG way.  These should either not be included in the general
  79 distribution, or rewritten to create and run tests in a system standard
  80 location-independent non-root fashion.  This is non-trivial, or I would
  81 have done it :)
  82 - The Parser (and other) classes main() functions are written in such a
  83 way as to not be tolerant of other command line arguments to the JVM,
  84 such as -classpath (which is required by the way JPackage does things).
  85 This is bad.  It means they don't work right with the rewritten scripts.
  86 The scripts are correct, but the Java should be fixed.  The scripts/code
  87 launch and work correctly with no arguments.  I never use the command
  88 line stuff, so I didn't bother to do this either.
  89
  90 The BIG question: Do you even exist and work on this stuff anymore (last
  91 update was years ago:), and if so, do you care to integrate any of this
  92 work into the z3950.org distribution???  (I know I was quite disruptive
  93 in my changes)
  94
  95 If not, I may just rewrite the spec to install the binary jar from your
  96 standard dist, and be done with it.
  97
  98 Thanks :)
  99
 100 --
 101 Chris Hubick
 102 mailto:chrish@athabascau.ca
 103 http://adlib.athabascau.ca/~hubick/
 104
 105
 106 __
 107     This communication is intended for the use of the recipient to whom it
 108     is addressed, and may contain confidential, personal, and or privileged
 109     information. Please contact us immediately if you are not the intended
 110     recipient of this communication, and do not copy, distribute, or take
 111     action relying on it. Any communications received in error, or
 112     subsequent reply, should be deleted or destroyed.
 113 ---
 114
 115
 116 --- StripMime Report -- processed MIME parts ---
 117 multipart/mixed
 118   text/plain (text body -- kept)
 119   application/zip
 120 ---
 121
 122
 123 From mike@miketaylor.org.uk  Mon Aug 29 16:45:11 2005
 124 Date: Mon, 29 Aug 2005 16:45:01 +0100
 125 From: Mike Taylor <mike@miketaylor.org.uk>
 126 To: chrish@athabascau.ca
 127 In-reply-to: message from Chris Hubick on Mon, 22 Aug 2005 15:17:48 -0600
 128 Subject: Re: CQL Java Distribution.
 129
 130 > Date: Mon, 22 Aug 2005 15:17:48 -0600
 131 > From: Chris Hubick <chrish@athabascau.ca>
 132 >
 133 > Hi.
 134
 135 Hi, Chris, sorry for the delay in replying.  We're in the middle of a
 136 complicated house-move, so I am less in contact that usual.
 137
 138 > First off, I have been using your CQL Java parser in my Metadata
 139 > Repository software for a few years now, and it's great!  Much
 140 > Thanks!
 141
 142 Thank _you_.  It's always nice to read this kind of thing.
 143
 144 What is your software called?  I don't think we've heard of it, but if
 145 it support SRW/U (as I guess it does if you're using CQL), then it has
 146 the nice property of Just Working with our metasearch engine, Keystone
 147 -- a fact that may be to both of our advantages to mention to possible
 148 customers.
 149
 150 > Second, sorry for CC spamming all the email addy's for you, I have
 151 > no idea which still works and you use for this type of thing.
 152
 153 No problem -- they all worked :-)
 154
 155 > Recently, we are moving our software into a production environment,
 156 > which means, as per our internal policy, I need to create RPM's for
 157 > all software involved (we use RedHat Enterprise Linux).  So, as part
 158 > of this effort, I sat down to create an RPM for CQL-Java.
 159
 160 That's a nice development.  Thanks.
 161
 162 > I *could* create an RPM spec file to just package up the
 163 > lib/cql-java.jar file, but as part of good practice creating RPM's,
 164 > the software should ideally be compiled from it's source into source
 165 > and binary RPM's.  This led to a number of problems, and my eventual
 166 > overhaul of your project structure.  Attached is a zip file which,
 167 > compared to the original distribution, does the following:
 168 > [snip snip snippety snap]
 169 > The BIG question: Do you even exist and work on this stuff anymore
 170 > (last update was years ago:), and if so, do you care to integrate
 171 > any of this work into the z3950.org distribution???  (I know I was
 172 > quite disruptive in my changes)
 173
 174 Wow, that is a LOT of changes.
 175
 176 To answer your questions: yes, I exist, but I don't really work with
 177 Java any more (though I hope to have a smallish Java project come in
 178 RSN).  I don't work on this stuff right now, but if the smallish job
 179 comes in as it promises to, then I will.
 180
 181 I'm afraid I just don't have time to make changes of this volume to a
 182 project that I'm (currently) not being paid for.  I hate to discard
 183 what you've done when it was clearly so much work, but I just not in a
 184 position to do the additional work necessary to understand it.  Sorry.
 185
 186 > If not, I may just rewrite the spec to install the binary jar from
 187 > your standard dist, and be done with it.
 188
 189 If you can bear it, I think that might be the best solution.
 190
 191  _/|_    ___________________________________________________________________
 192 /o ) \/  Mike Taylor  <mike@miketaylor.org.uk>  http://www.miketaylor.org.uk
 193 )_v__/\  "But I've _tested_ this code!  How can it go wrong?" -- Chris
 194          Martin.
 195