And They Shall Know Me By My Speling Errors

test from clever cactus

For those of you still following my weblog you all may remember that I had set Inst.Ant asided for a while while I pondered two problems, transactions and dynamic properties. I beleive I have solutions for both, but it may be a wile before I get to playing with them...

First on the issue of dynaimc properties, Costin has been a busy little bee over the holiday break, and has ported his changes relating to the dynamic properties support from his Embed proposal to the main ant line for 1.6. This means an end to evil hacks a d a more sensible solution to the ant call and properties problems. It may be a while before I get code written to exploit it, but as it is I need to wait a bit for PropertyHelper and friends to harden just a little. And then Ant 1.6 need so ship a FCS, which makes me shipping anything other than alpha quality code before that kinda useless. To paraphrase the greate M.Python "Inst.Ant's not dead (yet)."

Now about Transactions, how will I handle things throwing strange exceptions durring their executions (including ant build failure tasks)? What I plan to do is wrap all of the <do> targets into a try {} catch (Throwable t) {} block. It's a pretty wide scope but I want to catch errors too like OutOfMemory. I will then set an ant property holding the exception and set the execution order to undo. If the steps taken depend on failure or canceling or undoing then what that should be done on an error one can set the if= and unless= attributes to check for that standard property. The same will be done for cancel and (likely) normal forward back execution. If an error occurs in an undo the error will be re set, so there is the possibility of both a cancel and error flag being raised

So how does that affect transactions? It gives some greater control to the author to undo actions if stuff should fail, such as out of memory errors. While the granularity isn't directly to the level of individual task in the do/undo that can be fixed by the author splitting the do tasks to as many mutliples as are needed, to the level of one per do if that level of granularity is needed.

And in the interest of full disclosure, don't expect new code for a couple of weeks, at least. Family stuff and paintball is coming up, although I believe I have saciated my tase for NeverWinter Nights for a while longer.

I got a look at the dynamic properties code in the "Embed" proposal in the Apache Ant tree, and it looks like it will do quite nicely. It's actually better than I thought it was going to be: a AOP style interceptor pattern. Basically you register an PropertyInterceptor that intercepts the property get and set methods in a PropertyHelper class. This allows me to make properties set inside of or called by the wizard task mutable without affecting the rest of ant.

There are also some more rather interesting uses of the dynamic properties that are already in embed, the most interesting being the use of JXPath in properties, so you can do a property like ${/target[name='init']/@description} to get the description of the init task. Hopefully this will make the 1.6 release. I may start building Inst.Ant off of embed pretty soon, just as soon ans I stop playing Neverwinter Nights...

The truth be told, I haven't touched Inst.Ant for the past few days (not that I get more than an hour when I do). It was almost feeling like a second job how hard I was wanting to push it out as soon as possible. So given that and some technical issues with making a real quality piece of code out o Inst.Ant I think I am going to lay the project aside for a while. Who knows how long I will leave it there, but IMHO it seems that the technical reasons are enough...

Immutable Properties

This one has been bothering me the most of all of them. There are several ways that I can get around it, but none of them feel quite right. Each feels like I am shaving a different corner of the peg called Installer Framework or mis-shaping the hole that a set of tasks on top of Ant should fit into. I've seen some mention of somethnig called "dynamic proeprties" in the "embed" proposal in the Ant cvs tree and maybe ehtat is what is neede, but I haven't looked into it.

Lack of Transactions

I've seen Steve Loughran mention that a time or two, even recently on the Ant mailing lists. This really is a biggie... what if the first most base component you are installing fails, or a middle component? Do you quit with half an install? Do you continue? Do you roll-back? All three of those should be available to the install writer (in increasing order of preference). But there is no way to really group the dependencies together as an atomic transaction which at some level is essential for a good install. True, you could add <try> and <catch> fron Ant-Contrib, but then it ceases to be a declerative build script and becomes a programming language. Go write a custom progam at that point.

Maybe some time away may give me time too look at it from a different perspactive too... Maybe even I am approaching this wrong and I sohuld be writing a Java app that wraps ant and uses it as the work engine when it is assigned. Maybe some time will help me find the right peg, or the right hole may show up, or I may realize that the peg I am holding is sideways. Maybe I'll continue to enjoy Neverwinter Nights as well...

It looks like I will need to implement the <wizard> local properties definition and the ant call model for <do> sooner than I had intended. It turns out that the nature of immutable properties runs very deep in the ant code. When most of the core tasks are first initialized and run they resolve all of their properties, and if they are asked to initialize again some jsut ignore the request. Change a property and re-run the task and it doesnt take, because the propery value isn't supposed to change! (echo and condition are two examples).

I came across this trying to implement the install type to components mapping, when selected one, saw what was selected, went back and changed my decision. The radio buttons regarding my selection were preserved, but the do section activating the other properties executed the same as whatever my first selection was. Implementing the nested properties will also need to entail a build listener that listens to new property values that are applied to the project set of proeprties as they are set, a simple antcall clones (in a circuitious but needed fashion) the current build project and there is no passing back of the resultant propeties. There are tricks that can be done to get those properties but they seem too much to impose on the end user, it should be integrated and magically work.

The more I do this project the more I feel that there is a significant impediance mis-match between ant and an installer.

I've slowly been adding form controls to the form element over the past few evenings. With the addition of a text area control and a file chooser I now can create a wizard shell that could install Tomcat. It's not soup yet in may ways though. There is quite a bit of work to do for a weekend project (but if I had 40 hours a week time to spend on it I could belt it out in a couple of weeks, maybe one if there are no suprises). That is the problem with free (as in beer) software development, there's times I would much rather watch Harry Potter and I do.

The potential todo list on the immediate horizon (rest of Q42002) is as follows... (mind you that doesn't mean it will get done in Q4).

• Support radio buttons, and by condequence buttons groups. I would support one property-multiple values across the group and multiple properties-one value as well.
• Add if and unless attributes to all of thw form controls. Useful for summary and confirmation pages. Also for user data pages where another component may require extra info for a group of data.
• Add a progress bar widget that listens to do and undo steps and progeresses it. Also a text line that shows the last info level log from ant would be nice.
• Add console suppot for the wizard, right now there is no console support. None at all.
• Have at least some version of compon.ant out, so a single-jar install can be done.
• Lowest on my list is to refactor the properties to be held in the wizard model, as discussed in my Skinning a Cat Any Other Way... entry.

If anyone is following the CVS there are two new targets that may be of interest: demo and demo.tomcat. The first gives a short tour of all of the form controls (this is mostly what I use to test). The second shows the work in progress for a Tomcat installer, except for the fact it doesn't actually install anything. I am using it to gauge the look of the GUI. It looks better using kunststoff so I am using that in the Tomcat installer.

A better set of distributables and descritive web site will be coming when the code is closer to soup. I'de hate to have a page (other than my weblog) promising good stuff and sitting stagnet for a year.

Yep, just as I suspected my request to add a remove properties api was rejected (as a duplicate to a non api variaty of the request). No schocker really.

But I do have a better idea how I can better handle this without resorting to evil (but really useful) hacks. First the wizard task will keep it's own set of properties outside of the ant Project, reflecting non-user properties as pre-existing defaults. The Do and Undo elements will behave more like antcall, they will have a target attribute that an instance of the project will be created with the properties from the wizard task, like antcall. Body tasks will still be supported in lieu of the targ attribute (if the code isn't to henious), but a synthetic target will be created in the project containing all of those tasks.

I almost got my evil scheme to work...

try {
    Field fieldProp = Project.class.getDeclaredField("properties");
    fieldProp.setAccessible(true);
    Hashtable props = (Hashtable) fieldProp.get(project);
    props.remove(property);
    fieldProp.setAccessible(false);
} catch (Exception e) {
    project.log("I got caught with my hand in the cookie jar: " + e);
    project.setProperty(property, "");
}

I can access the properties object, but only in jdk 1.2+. The API I need to access a private field is java.lang.reflect.AccessableObject, which wasn't present in JDK 1.1.

So I am at a crossroads... and what I am leaning towards is to drop JDK 1.1 support. It kinda works but will be rather broken for most install tasks. The other option is to try and add a removeProperty method to the Project class, but I would either need to fork it or get it into Ant 1.6. Forking for a legitamite API reason is just as unpallitable to me as forking for political reasons. As for the other path I bet that a bug for adding a removeProperty method would get shot down for design reasons, and I couldn't say I'de blame them on that one either. Oh well...

After getting a better feel of XForms I have decided to roll my own form pages rather than using an existing XML format. I initially didn't want to create yet another xml to widget mapping, but nothing quite matches what I need. I even took a look at jelly-swing but there is way to much binding to the swing architecture when you consider that a console mode and non-swing GUI are in the initial design premise. So I am going to roll my own. Case and point, how does one make a checkbox show up with XForms? You do either (a) <input ... /> that is bound to an xsd:boolean value in the model, (b) <select appearance='full'> with one <item/> child. Both are counter-intuiotive to me and I would rather have one <checkbox /> element. I will use some ideas from XForms: like the nested label and help elements though.

That was Problem #1. Problem #3 was roller eating my post because of session expiration. But problem #2 is how to handle ant properites. Anyone who has done much with a ant build.xml knows that the variables ant users are set conter to the typical programming: the first setting of the variable sticks and later sets are totally ignored. This actually makes sense when put in context of a user-overridden values on the command line. But when taken in context of a "back" button in a wizard a first-set-win policy demolishes the concept of going back and changing values. There are two tasks, ant and antcall, that break that rule, and wizard will have to be another one. Overcoming the rules isn't that much of a problem with the ant APIs.

The true problem comes in unsetting the properties, there is no way via the APIs. You can get a Propeties object but that is just a copy, not the local value. So you cannot un-set a value. But the if and unless atributes go by whether the property is set or not set. I considered making some of my elements sensitive to true/false values, but the target would not be sensitive. This would make using properties to drive the dependent component installs impossible, which was the whole point to me of using ant to do the installs: to declaritively determiine the needed dependencies. But it's not insurmountable. The magic of introspection allows me to forcably introspect the values and change them. For anyone who thinks that RTTI is wrong, add me to your list of violaters.

I now have the Wizard task working more or less how I like it. As per my previous posts putting header and footer inside of the prompt made for a more intuitive look and feel. I also added if and unless attributes to do, undo, prompt , doPrompt, and undoPrompt. To see all this in action you can downlaod the CVS and run "ant test". Documentation is non-existant, but I never intended to address that until it was truly ready for public consumption.

The next target will be to get some semblance of the formPage element working for the prompts, so some interactive pars can begin and I can start trying to make a real install wizard for something usefull.

My original concept of the wizard task children was a set of items that would be evaluated in forward or reverse order based on what the user said at the prompt elements, but based on what I have coded it will not quite work. Consider pseudocode of my first approach in my test file...

sidebar image A
prompt 1
sidebar image B
prompt 2
sidebar hide
prompt 3

This would describe three wizard pages, the first with sidebar image A, the second with sidebar image B, and the third with no sidebar. You would expect that if you go to page 3 and go back to page 2 that you would see sidebar image B, well in the simple algorithm I coded you would stop at prompt 2 but no sidebar image would be produced. Going backwards from prompt 3 you would encounter sidebar hide and then get to prompt 2. Back again would bring you to sidebar image B and then to prompt 1. But sidebar image A would never be seen once passed. This can be coded around...

sidebar image A
prompt 1
sidebar image A
sidebar image B
prompt 2
sidebar image B
sidebar hide
prompt 3

But this sends a shiver down my spine as being (a) ugly and (b) brittle due to code duplication. Clearly just going forwards and backwards will never work, and I never realized that because how often do you write code that is intended to be run backwards as well as forwards? Even when you kick out of a transaction the code is read forward but you just unlock in reverse order you gained the locks. It's like a stack, going back down in it is still coded in a forward fashion.

So here is my current thinking (but the names of the elements may change, suggestions welcome):

<wizard> : wizChildren
<step> : wizChildren
wizChildren : (<step> | <prompt> | <do> | <undo> | <doDisplay> | <undoDisplay>)+
<do>: ant tasks
<undo> : ant tasks
<prompt> : promptChildren
<doPrompt> : promptChildren
<undoPrompt> : promptChildren
promptChildren : <sidebar>?, <header>?, <centerPane>
<sidebar> : splashChildren
<header> : splashChildren
<centerPane> : splashChildren, <formPage>

Rather than having the sidebar and panel be direct children of the wizard task, they are direct children of the prompt element, or the two new ones doDisplay undoDisplay. This makes what should be a "page" more atomic, and also separates the page from the transition code between those pages. The doDisplay and undoDisplay elements allows for the wizard page to be changed during execution of long tasks without soliciting "must respond" interaction. There are still some nuances for cancelable tasks and ordering, but those don't look offensively ugly like the first approach. Given this re-design the pseudo code would look like...

prompt 1
    sidebar image A
prompt 2
    sidebar image B
prompt 3
    sidebar hide


It doesn't look too different from the initial but this is a simple example. A more complex example would have betrayed just how bad my first look (it would border on un-readable). Hopefully it would also show just how much better this new approach seems too me right now, bit I haven't coded any really complex stuff.

On a different note I have decided on an initial goal and litmus test for deciding when the various parts of Inst.ant are soup: Can it install Tomcat? For inform.ant it will be can it gather all the install data for Tomcat. For propell.ant it will be when it has the tasks to do all of the nifty platform specific stuff like application menu items, service/daemon instillation, proposal of good default locations on Windows, Linux (ReadHat 7.3), and Mac OS X. For compon.ant/redund.ant it will be single-jar instillation of the precious. And for dist.ant it will be native executables for the same, although that task looks kind of distant.

Back from dinner. We tried a local mexican restaurant that seems to be good, better than the chain sit-down establishments we have tried.

Now, back to to body content of the <wizard> task. In addition to the operational tasks we need to update the images along the way, so we add <header>, <sidebar>, and <page> elements to handle the top, left and middle portions of the traditional wizard. <header> and <sidebar> will be treated in a similar way as the splash pages, except that they will show for the duration of the wizard or until a <header> or <sidebar> with a new attribute display="false" is encountered. The border and sidebar panes will be missing before one of these is encountered and after display="false" is encountered.

The <page> element is where most of the interesting stuff happens. Previously I stated that I was going to use HTML 4.01 forms for the content model of that page, I changed my mind. First, <input type="ugly"/> looks heinous. Second the Java Look and Feel suggestions for wizards mention context sensitive help, like one for each form element if needed. XForms in it's current rendition includes a help element that goes with each control. It also contains hint elements that I intend to use as tool tips. So what I plan to use is an arbitrary sub set of XForms with some changes of my own. The first being that the "upload" control will be re-named "fileChoose" and will be able to select directories.

So that looks like the gist of what will be there, sans attributes.  I'll invent some hacked up BNF/DTD representation as a summary:

wizard : %wizChildren%
step : %wizChildren%
%wizChildren% : (step | header | sidebar | page | prompt | do | undo)+
header: (image | htmlPage)
sidebar: (image | htmlPage)
page : %inst.form%
prompt : -emptey-
do : %antTasks%
undo : %antTasks%

Java on the other hand has some particular allowances for what can be put on the left pane which segues nicely into some of the functionality that a wizard needs, namely to skip some pages base on user values or other reasons. For example when you select "standard" install you shouldn't get the pages with all of the custom component selections. This will be handled by the child <step> type of the <wizard> task, which will be able to contain all of the same children that the wizard task contains. These would both support "if" and "unless" attributes.

The next thing we need to handle is "next" and "back". This would be handled by a <prompt> element that would indicate the buttons that can be showed and their state. Then we would need <do> and <undo> elements based on what the user selected in the prompt. These would just be re-named sequential elements with "if" and "unless" attributes. (cancel would unwind to the beginning and exit).

Well, I got to go meet my wife for dinner so I'll go deeper later this weekend.

Normally I wouldn't post about every CVS drop of Inst.ant, but this is the first one. Not a whole lot is there yet, but the splash task is as done as I'm going to make it until I either get the wizard task in working order or new bugs are reported against it.

Most of the interesting stuff is, as always, in the CVS. I have only posted the compiled jar and the docs for the one task, but the CVS has source code and a few test cases I wrote for it. Once wizard is in some working shape I'll do a better web site for it.

Ok, how does one determine the size of a text field from the maxInclusive="12345" field of a XML Schema xsd:element? Does one do this (packed into one statement or many as tastes dictate)...

String maxInclusive = element.getAttribute("maxInclusive");
double d = Double.parseDouble(maxInclusive);
d = Math.log(d + .9); // for the case of 100, we need 3 not 2
d /= Math.log(10);
d = Math.ceil(d);
return (int)d;

That's what I intially did. Too much time spent in math classes in high scool and college I guess. That blinded me to the more elegant solution... return element.getAttribute("maxInclusive").length(). And I even spent time looking online to verify that log₁₀(x) is ln(x)/ln(10) after the guy with a degree in statistics couldn't remember for certian!

Just printed out the XForms working draft specification, it is quite a beast at 169 pages. I was thinking that when I did the wizard I would do some sub-set of this, but the functionality it calls for is another open source project in and of itself. It tries to cover every possible use of forms under the sun and under the moon. So when I design the wizard task I will be using some subset of the controls from XHTML 1.0 which is to say HTML 4.01.

Not that I wouldn't mind implementing XForms, since it specifies a standard model of the widget dynamically interacting with each other. Most complex installers have that to some degree (like checking the "use proxy" checkbox on one page and then all of the other items enable themselves). But I would rather have some Compon.ant, Propell.ant, and Redund.ant parts complete before I would come back to address that (in about a year or two when the spec is complete anyway).

So then what will be available is check boxes, radio buttons, text boxes, text areas, password boxes, selects, lists, and labels all syncing their values to project properties. Items can be enabled or disabled but on the first pass through that will only be evaluated on next/back transitions.

I got the sourceforge stuff set up for the Inst.ant project. The info page is at http://www.sourceforge.net/projects/instant/. Hopefully by Saturday I will have some code up. Some progress is coming on the splash task but that is small cookies compared to what should exist for the inform.ant piece. But there will need to be a good amount of forward design before I start to code the wizard.

Time to drill down onto the <image> and <htmlPage> sub elements of the <instSplash> task.

<image> - href, file, or resource are required and mutually exclusive.

• href [java.net.URL] - A URL to the image to use.
• file [java.io.File] - A File containing the image to use.
• resource [String] - A java class resource resolved via ClassLoader.getResource().
• classpathref [String] - A ref to a named classpath element. This classpath will be used to get the image if the resource attribute specifies the source.
• <classpath> - As per the standard classpath element. First the classpathref, then each of these in document order will be used to find an image specified by a resource attribute.
• resize [String] - One of "center", "stretch", or "tile". If the splash panel is not the same size as the image this is how the size discrepancy will be addressed.
• backgroundcolor [String] - The background color of the splash screen for this image. Useful for images with transparency and center resize policies. The value must return a color from either java.awt.Color.getColor(String) or java.awt.Color.decode(String) (in that order) or the default panel color will be used.
• #PCDATA - Will be used if the installer is run in "Headless" mode (either by a future configuration or a java.awt.HeadlessException). Contents will be output to the console. (this will need another look for i18n).

<htmlPage> - href, file, or resource are required and mutually exclusive.

• href [java.net.URL] - A URL to the HTML Page to use.
• file [java.io.File] - A File containing the HTML Page to use.
• resource [String] - A java class resource resolved via ClassLoader.getResource(). There are implications with relative URI references here, so it will definitely be addressed later rather than sooner.
• classpathref [String] - A ref to a named classpath element. This classpath will be used to get the HTML Page if the resource attribute specifies the source.
• <classpath> - As per the standard classpath element. First the classpathref, then each of these in document order will be used to find a HTML Page specified by a resource attribute.
• <html> - The actual content of the HTML page in XHTML(may be cut out). This seems to be a pipe dream since Ant does hardcore parsing of all of the elements and I cannot just pass in the children as a org.w3c.dom.Node or NodeList and flatten it to text. But this is what I would like to do.
• #PCDATA - Will be used if the installer is run in "Headless" mode (either by a future configuration or a java.awt.HeadlessException). Contents will be output to the console. (This will need another look for i18n).

Those are the end-user use case for the instSplash task. The design would need to use a factory to handle whether it is being run in Swing, console, SWT, or AWT mode. I'll address that later should I start writing code for this.

After reading the new Appendix E from the Ant 1.5.1 distribution I realized that there is already a task named "splash" in the optional tree. I went and looked at it, but it is not what would be needed for installer type items. I want more!. It is a coole idea, with the progress bar and such but (a) the progress bar incraments one value per build event rather than a 100% progression and (b) it's locked into images only with a pack and center approach only. The progress bar has some implications for the Propell.ant portion.

Here's the sort of stuff I would put into the Inform.ant splash task, which would need to be called something like instSplash:

• zoom [String] - How the splash page would be shown, one of "fullscreen", "packed", or "fixed".
• width [int] - Width of the spash panel, for zoom="fixed" only.
• height [int] - Height of the spash panel, for zoom="fixed" only.
• decorated [boolean] - Whether or not the spash window should have decorations (frame border, open/close/zoom buttons, etc). A flag for either calling setUndecorated(true) or putting the frame in a JFrame or a JWindow.
• <image> - Shows an image in the spash window (more detail tomorrow).
• <htmlPage> - Shows an HTML page in the spash window (more detail tomorrow).
• <sequence> - As per the existing sequence tag: do the embeded items singularly in order.
• <parallel> - As per the existing parallel tag: do the embeded items in parallel and join threads at the end.

The child tags could be put in any number and what the instSplash screen will do is show each image or html page as they are reached, and then do the intervening tasks. Much like some old school installers would do when you press the "install" button: showing adverts for other products by the company as the install progressed.

After thinking about it it looks like Inform.ant will consisit of 2 (maybe 3) ant tasks. One for a splash screen, one for a wizard, and possibly one to handle random dialogs. There is also a longer term goal that the forms defined by Inform.ant could be used with a variaty of methods. The first will be swing, the second command line (possibly with pre-answered questions). Then possibly SWT and or ANT (for 1.1.7 jview run installs) but those would be after compon.ant and propell.ant. So where it makes sense I am also thinking about these in context of a headless or scripted mode.

Splash task -
The task definition itself will only handle the details of the window it is a slapsh for. Size, location, etc. The children will be the actual content and the tasks to be performed with it. I imagine a <image> and <htmlPage> child to support an image or a HTML page as the splash screen. Then either a tasks element (subbing off of sequence), sequence and paralell themselves, or the other tasks themselves as children.
The reason behind not putting the splash stuff all under attributes to the spalsh task would be because sometimes the spalsh content may want to change as the work progresses. Much like your typical symantic install process. The sizing attributes would have to take into account multiple size images and htmlPage possibly too.

Wizard task -
This is, quite clearly, the more complex task of the two. The idea would be the same, the outer wizard task would just contain frame information and stuff like the name of an ant task to do on cancel and such. The Children would contain the guts of the wizard and the aditional tasks to be done durring the wizard.
This task could be quite involved, especially since I am going to be following the Java Look and Feel Guidelines for wizards. I would like to allow for as much of the functionality describes there as possible.
As for the form components themseles, I will probobly follow a sub-set of XForms, except that the fields will be tied in to Ant Proeprties instead of an XML instance. From those proeprties different tasks for different install options can be triggered.
I should also provide an interface to be impementd so that custom pages can be defined in Java themselves. But a goal would be that 80% of the uses of Inform.ant could be done declaritivly in the Ant Script itself. To do this however I may need to enlist the help of the script tag and re-defining of ant variables.

As for dialogs, I don't know about what I will do. Prohaps I will just support the 4 basic ones from JOptionPane with no wierd stuff (like custome fields). I can see how I would need those.

My current plan however is to get the splash tag written and then get some more design done for the wizard tag.

After writing my previous entry on Inst.ant I have does some more thinking on it and may go forth with a simple and non-aggressive plan. Who knows how far I will get on it with the time available.

1. Inform.ant - This is the first baby step. It will be a set of Ant tasks that create wizard-type forms and can call other ant targets and embed other ant tasks as part of their execution. The idea is that ant properties would be set and tasks would be called from them. I have some thoughts on this that I will detail later. The name is a play on the word "form" as windows folks like to call GUI frames.
2. Compon.ant/Propell.ant - The next step would be self-packaging of the install scripts (but not totally self sustaining). Compon.ant would assemble the nesscicary files into jars and handle the accessing of them at run-time when the installer is run. All-in-one packageing would not be addressed in this stage but a single jar presuming a jre would. The Propell.ant part would be the changes and redundant ant tasks that would be needed to handle URL and input-stream based tasks, such as unjar, copy, filter, et. al. (all of those are currently file based only). And yes, I know component is the real spelling, but I got a theme going here
3. Dist.ant - This would be the final stage. Each built on each other and useful on their own. This stage would address all in one packaging including specifially the embedding of the JRE needed to run the Inst.ant archive. Shell scripts for unix and .EXEs for windows. I know some shell tricks for unix but windows would be more involved.

Of course this may be pipe-dreaming because it is a function of available and budgeted free time.

Occasionally I get some ideas for OSS Projects that would be nice to do but I never attempt because I lack the time (If I do more than 50 hrs of coding and such and productivity drops dramatically, plus I don't think my wife would appreciate it).

One that has been with me for about 2 years is one I call 'Inst.ant', basically it is a set of tasks and other tools to allow people to build an installer built almost entierly out of Ant build files. From definition of the GUI splash screens and such all the way down to the actual instiallation code itself. The name is sometimes as importiant as the project itself so that is where the name comes from -- Inst for Install and .ant for the fact it is totally Ant centric.

Of course like all kewl ideas like that I never have enough time to execute them. Another de-motivator for me is that there is already another open source jva installer izPack. It's not a total category killer though, since it is GPL and Inst.ant would probobly be Apache Licence. A perfect opportunity to throw gasoline on the open source licence holy war.