From the website: ---------------------------- DataWorkshop is an editor to view and modify binary data. The editor provides different views which can be used to edit, analyze and export the binary data. A simple hex view can be used to simulate a standard hexeditor but more complex dynamic views are possible to comfortable edit binary structure like executables or captured network traffic. The editor provides powerful search and diff functionality and user defined transformations to modify the binary data. Views can be filtered using the XPath query language (e.g. selecting several IP packets in a network traffic capture file) Views can be exported as in various formats for further processing. This can be used to convert old binary formats into modern xml tagged data. ---------------------------- It's a pretty groovy app. There's a couple of weird things about how it works and how the ebuild is put together, which I'll describe momentarily as I attach files. Reproducible: Always Steps to Reproduce:
Created attachment 32219 [details] dataworkshop-1.1.ebuild Here's the ebuild. Some things to note: 1) There's no LICENSE specified. That's because they've got a rather freeform "Freeware" license specified on the site which, being homebrew, isn't available in /usr/portage/licenses. I'll attach a text version of the license they use momentarily. 2) No src_compile... This is a binary Java app, which'll be going into /opt, so there's nothing there. 3) The program expects its entire tree, including docs, to be present at the level where the main Jar file is, so in addition to "dodoc"ing and "dohtml"ing the docs, they're also present under the installation root. (Obviously feel free to change at will) 4) There's a wrapper script there, which'll essentially execute "java -jar DataWorkshop.jar." There are some other issues going on there, but I'll get to those as soon as I attach the wrapper script itself.
Created attachment 32220 [details] dataworkshop (wrapper script) Here's the "dataworkshop" script which'll theoretically live in /usr/bin. It's a bit funky, you'll probably end up completely changing it around, but this one works at least. Some things to note about how the program runs: 1) As far as I can tell, you *have* to run the program from the same dir as DataWorkshop.jar. It seems to try to open files directly, so simply adding in /opt/DataWorkshop (or /opt/DataWorkshop/DataWorkshop.jar) to $CLASSPATH doesn't seem to do anything. This brings us to the second point: 2) The program stores its XML preferences files in the same dir it was started under. This means that we can't just run the java command from /opt/DataWorkshop, because your average user isn't going to have write permission to that directory. So, the way I solved that problem was to create a ~/.DataWorkshop and then symlink everything over so that there was a little sandbox to play with. Now, the weirdest part of all this: 3) You'll note I create a .javaSystemRoot dir under .DataWorkshop, and then reference it with a -Djava.util.prefs.systemRoot setting. The reason why is thus described in more detail that I'd be able to muster: http://www.allaboutbalance.com/disableprefs/index.html Essentially, due to some weirdness in Java 1.4, anyone attempting to run this app on their Linux/Unix/Whatever machines will end up with the process trying to write files into /etc/.java, despite the fact that this app doesn't even use that preferences system to store its preferences (it uses the XML files stored at the base dir). The website listed several possibilities for dealing with this behavior, and I felt that simply redefining the system dir to something under ~/.DataWorkshop was an acceptable solution since the app doesn't even use that framework. So that's what that's all about.
Created attachment 32221 [details] LICENSE This is the license, available on the website or in about.html in the included docs/ directory. Nothing special here.
One other thing, if you're testing this out for usability and notice that there's some funky stuff going on with saving preferences (NullPointer errors and miscellaneous SAX reader errors), that seems to be a bug in the software itself, and doesn't have anything to do with the symlink sandbox I had set up. I've seen the same problems on an ordinary just-unzipped-and-running-it-with-write-permissions-and-everything install. Obviously I think the program's cool enough to warrant me slogging through all this stuff to get it ebuilded, though. :) Anyway, there it is.
Looks like there's a 1.1.1 version of this which is under a more usual opensource license. I'll take a look at it later today and bring the ebuild up to date.
We are not adding binary java stuff to the tree any more. Feel free to reopen with a source ebuild if the thing is still alive upstream. WONTFIX.
