PackIn Results

1. Sample PackIn execution showing unresolved objects

2. Package Maintenance snapshot showing the successful objects created (which is incomplete for the whole module to show up)

2Pack retains information about the success or otherwise of any PackIn execution.
Screen on the right shows after running PackIn process on the selected zip file in the Package Source field.
The zip file is a Menu summary with 2 sub-menu windows each having singular tabs with some fields.
The process ended with a status of 109 Processed and 25 Unresolved items.
(Note that i have to amend the sub-menu tags <A Menu> with a type = "table" as a temporary hack as reported in the issue tracker. Without the tag, the PackIn won't proceed to the later elements.
After PackIn, 2Pack has a Package Maintenance window to show the details of the PackIn (see image 2).
As you can see, the two sub-menus did not come through and thus it breaks the display calls when we refresh our ADempiere.
The Columns are also missing. However it is great that the rest in my sample came out ok.
From here as reported in this issue tracker, i began my debugging to find out what is actually happening.

Let the Debugging Begin

3. Packin status showing objects resolved with no unresolved.

4. Final PackIn Success! - Note the bottom rows showing the sub-menus successfully negotiated into the DB

5. The freshly PackIn Module with the Summary Menu, sub-menus, 2 Tables opened up and working right away!

I will now detail the total journey taken to debug the 2Pack module code and the interesting things that comes across. It is very educational to introduce how this legacy 2pack as inherited from many hands starting from Marco Lombardo, Robert Klein, Carlos Ruiz, Trifon Trifonov and so on is now refactored under OSGI HengSin. We shall see the relevant code snippets and the Element stack that stores the XML info. Then we see how each element is reproduced into the AD.

My environment makes use of Eclipse on a MacBook Pro.
Codebase is completely OSGI HengSin on latest 360LTS with migration scripts applied and edited to avoid unnecessary ModelValidators.
When i PackOut the xml and zip, i restore my DB to prior the creation of the Africa Module (comprising of Flight Schedule and Booking windows).
Then i PackIn from the zip file noting and tracing any bug.
When i want to run the test again i restore again the DB.
- A good trick in Eclipse to avoid reruns is to use the Drop to Frame technique which will put the execution back to the start of the frame in the thread stack during stepping through.

Essentially, the 2Pack is an xml file and thus the PackInHandler accesses each xml tag and process it.
As an AD structure has corresponding sub-tables i.e. AD_Menu to AD_Window to AD_Table, so the XML reflect them as and arrangement of tags and sub-tags, been processed as properties or children of the Element Interface used to represent the XML structure.
Has 3 important stages in the class:
- startElement which handles each element's start-tag in the xml file. After some formatting the element is stack.push to consolidate it.
- endElement which handles every end-tag in the xml file with stack.pop to remove the temporal elements down to the final consolidated element.
- processElement when the stack.isEmpty() where the final Element instance has stored the whole XML structure and its contents which is now ready for the actual process of creating the AD.

During cursory examination of my PackOut.xml i cast the first doubt if the following xml info is processed by the PackInHandler.

 <AD_Menu type="table">
            <Parent_ID reference="table" 
                   reference-key="AD_Menu.Name">Afrikiya</Parent_ID>

This element info clearly help links the sub-menu to the parent menu, of which has not happened as seen in the 2nd image above.
I looked closer at reference handling of the child 'parent_id' tag to see if it is passed by or failed to take effect in MenuElementHandler.
Then i found out it does and now i bring my attention to the Defer Method.
Eventually HengSin resolved the latest issues and we can now see masterpiece in images 3, 4 and 5.

So now we have some good news and bad news. The bad news is this roller coaster fun debugging into the 2Pack codebase has to stop for now (until we hit something else).
Good news, the 2Pack works nicely with the latest issue fix by HengSin on Revision 6635 to 6641.
Now PackIn can handle different PackOuts such as attached in this Kenai tracker.