The first packaging effort and addition of the OdmDeploy100 portion of the development tree occurred with the 0.58beta release. With the 0.59 beta transition candidate, that portion of the development tree is renamed OdmPackage100 to avoid confusion with the broader deployment topic.
The documentation and formalization of the packaging approach, along with refactoring for smoothness, is part of 0.59 Public Beta Transition Candidate development. Along with other elements of 0.59beta, this activity is a dress-rehearsal for the approach to be used with 0.60beta.
This folio is created to carry those 0.59beta work items pertaining to ODMJNI packaging.
- 2007-10-09-18:39 No Automation for Now
- The 0.30-practical100 regression set can be automated because it does not have any dependencies on presence of the ODMA Connection Manager or any DMS integrations. The other regression sets cannot be automated because all of those confirmation tests depend upon human interaction and availability of an end-to-end connection through to an ODMA-compliant DMS integration. Until we are able to substitute some sort of automatically-driven back end stack, there is nothing to be done here. (Note that one substitution could be with odmjni100 but it seems far better to do it on the other side of the ODMA Connection manager with a mock integration that can be used in many other cases.)
- 2007-10-09-18:34 It is OdmPackage100!
- I reviewed all of the manifests and scripts in the OdmDeploy100\ tree. There was only one dependency on that name, and it was in an example within ODMJNI100.txt. This will be easy to repair. There is no place that actually depends on the name of this portion of the tree.
- 2007-10-08-14:24 Is it OdmDeploy100 or OdmPackage100?
- When I created this folio, I said that the relevant portion of the development tree would be renamed OdmPackage100. That is reasonable to do, since deployment is maybe broader. I have mixed feelings about this. It will depend how things look when I get to where the OdmDeploy100 tree is reviewed for revamping for 0.59. If I can rename easily, I will. If it is going to be renamed at all, the sooner the better.
- 2007-10-04-18:30 Working Regression Sets into the Runtime Packaging
- The ideal place to have regression sets is as part of the runtime packaging. This means I need to figure out how to move the practical100 and odmjni100 regression sets under the OdmDeploy100 structure and make part of the Runtime deliverable. Anyone should be able to repeat the regression tests, and set up to do them, not just the OdmClicker test or anything that replaces it. (OdmNative100 is spun out into a separate project so its regression is separate. ODMJNI 1.0 is an adopter of OdmNative100, not its provider.)
The challenge is to have this one set work for regression on the final "build" -- the runtime packaging, a Jar file in the class path or adjacent to an application, and also with new code in the development tree where the class path is into the source tree where new modules are being developed and tested.
If I need a branch in the script, I should make the default be that the program runs as a regression against the package. I could also have these scripts called by scripts over in the development tree. All things to think about.
- 2007-09-24-08:00 Thoughts on Minimizing the Packaging/Installation Surface
- Reflecting on an experience with the OpenOffice.org installer, I was thinking how much installer bloat costs when excessive material is installed on the end-user system. When both the distributed package (say a released .exe file) and the installation files have to be retained for uninstall and upgrading to work, that is a serious burden. Done badly, it doubles the space taken by material (not counting the after-installation software), it burdens hard-drive maintenance (disk optimizers have to look at all of it), virus scanning (and adds to the computer threat surface), and most of all it is a fragile arrangement depending on user participation when it should be built into the installed application files.
ODMJNI 1.0 is mostly repackaged by application developers to go with their package. Still, I want to package everything in a way where the minimum baggage is carried along and the amount of ODMJNI 1.0 needed for different purposes can be selectively extracted. I also want to provide guidance so that application developers can confidently incorporate ODMJNI packaging in their distributions and that anyone can troubleshoot that the ODMJNI portion has been installed successfully.
Dennis E. Hamilton: OpenOffice.org: Installation Hot Tip! Orcmid's Live Hideout (web log), 2007-09-24.
- 2007-09-23 Needing to Take OdmDeploy100 Seriously
- I introduced the OdmDeploy100 portion of the development tree as part of creating the .jar and runtime packages that were included with 0.58beta. But I didn't remember that there is no place where that material and its maintenance is documented in ODMdev until taking apart my 0.59beta progression statement from 2007-09-20 for distribution of the major items to the devNotes where those items are to be accounted for. I might find something in older notes, as they are recovered retroactively, but I'm not expecting that.
- Hamilton, Dennis E.
- ODMJNI 1.0 Packaging - 0.59 Public Beta Transition Packaging. AIIM ODMA Interoperability Exchange, ODMdev Development Note page d070901c 0.02, October 9, 2007. Available at <http://ODMA.info/dev/devNotes/2007/09/d070901c.htm>.
created 2007-09-24-15:47 -0700 (pdt) by