1 From mike Tue Aug 23 09:00:42 2005
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
15 X-StripMime: Non-text section removed by stripmime
16 Content-type: text/plain
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!
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.
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
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
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
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
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.
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
95 If not, I may just rewrite the spec to install the binary jar from your
96 standard dist, and be done with it.
102 mailto:chrish@athabascau.ca
103 http://adlib.athabascau.ca/~hubick/
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.
116 --- StripMime Report -- processed MIME parts ---
118 text/plain (text body -- kept)
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.
130 > Date: Mon, 22 Aug 2005 15:17:48 -0600
131 > From: Chris Hubick <chrish@athabascau.ca>
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.
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
142 Thank _you_. It's always nice to read this kind of thing.
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
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.
153 No problem -- they all worked :-)
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.
160 That's a nice development. Thanks.
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)
174 Wow, that is a LOT of changes.
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.
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.
186 > If not, I may just rewrite the spec to install the binary jar from
187 > your standard dist, and be done with it.
189 If you can bear it, I think that might be the best solution.
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