The Number specifications don't allow large enough values for the Min/Max/Null/Unknown values. I want to support 100 digit numbers across the board.
The models have been refreshed to specify 2016 licensing.
Note that the code produced by 2.4 no longer fully compiles due to changes in the SAX parser base code provided by CFLib 2.5. However, the pieces that are needed by MSS Code Factory 2.5 itself build successfully, so I'm not going to spend time fixing obsolete code.
Reverted and re-converted Obj.java.
There were a couple of cleanup items to take care of, so I've rebuilt and repackaged the main for MSS Code Factory 2.4, even though it is only used to manufacture the code for the 2.5 engine.
There were a few places where I neglected to shift from v2_3 references to v2_5 references. That has been corrected.
There were some bad references to SecuritySchemaName and to v2_3 code being produced for the CFCore build. CFCore relies on the cfengine cartridge, which is different than the "standard" Java rules because it has to deal with system internals and can't reference CFCore directly (as it's manufacturing CFCore itself.)
I almost forgot to update the CFLib and CFCore references from v2_3 to v2_5 before doing the runs.
The 2.4 release is only used to produce the 2.5 engine code, but it also takes care of the migration from CFBam 2.3 to CFBam 2.4. With any luck, CFSecurity, CFInternet, and CFBam 2.5 will look the same as 2.4 save for the version number changes, which will make the development of the 2.5 release trivial.
Surprisingly enough, it took less than 3 hours to migrate the 2.3 code base to 2.4. I expected it to take a day, but thanks to some creative edit scripting, I got it done much faster than that.
CFDbTest 2.4 has been regression tested with PostgreSQL, and all of the 2.4 projects have been successfully built using the refactored architecture of MSS Code Factory 2.3.12994 SP1.
There was more debugging required than I expected, but CFDbTest 2.4 now passes it's regression tests for PostgreSQL. I won't be doing full regression tests of the other databases because the only thing that changed in the DbIO layers is the name of the buffer and key objects, not the actual JDBC code.
Due to the changes required to get CFDbTest 2.4 to build, the core projects have also been remanufactured, rebuilt, and repackaged.
CFDbTest 2.4 is now ready for some testing.
The builds for CFSecurity, CFInternet, and CFCrm 2.4 now completes successfully.
The Swing prototype GUI now builds for CFCrm 2.4, as well as the main for the HTTP client GUI.
The four XMsg layers (XMsg, XMsgRqst, XMsgRspn, and XMsgClient) now build clean.
The SAP/Sybase ASE layer now builds clean for CFCrm 2.4, and the SAX Loader mains for each of the databases also build clean. Next up are the XMsg layers.
The PostgreSQL layer now builds clean for CFCrm 2.4.
The Oracle layer now builds clean for CFCrm 2.4.
The MySql layer now builds clean for CFCrm 2.4.
The MSSql layer now builds cleanly for CFCrm 2.4. I am no longer going to do the builds for CFSecurity and CFInternet, as the CFCrm build catches all the mistakes and errors in the rules that the first two, as well as a few others.
The DB/2 LUW layer now builds cleanly for CFSecurity, CFInternet, and CFCrm 2.4. Next up is the MSSql layer.
The SAX XML parsers build clean for CFSecurity, CFInternet, and CFCrm 2.4.
The Buff, HBuff, PKey, HPKey, and various index key buffers are now only created by their defining schema. The bring-forwards from the imported projects have been removed for CFInternet 2.4 and CFCrm 2.4. CFSecurity 2.4 is unchanged, of course.
The base, Obj, Ram, and MssCF layers now build successfully for each of CFSecurity, CFInternet, and CFCrm 2.4. Only CFSecurity 2.4 builds completely, of course -- both CFInternet and CFCrm fail on the next layer: the XML SAX parser.
CFSecurity 2.4 builds completely. CFInternet now builds the core jars and fails on the next ant step: the msscf layer. The state of CFCrm 2.4 has not been checked yet, but a source refresh is being delivered for CFInternet and CFCrm even though they don't build yet.
CFSecurity 2.4 has been completely built and packaged.
Only a source zipfile for CFInternet 2.4 and CFCrm 2.4 are being provided because only the core/base and Obj layers compile so far.
I'm still working on getting the core layers to build properly at least two layers deep (CFInternet). Then there are all the supporting objects which will have to change from SchemaName to DefSchemaName specifications in a number of locations. It's going to be a lot of work getting this to a clean building state for CFInternet.
CFSecurity still builds ok.
This checkpoint release sees CFSecurity 2.4 building cleanly again.
CFSecurity 2.4 now builds cleanly with the code manufactured by 2.3.12952.
That isn't to say that it's going to produce valid code for CFInternet 2.4 and the subsequent sub-projects, but it's a start.
The core packages defined by the lowest layer of the class hierarchy are now properly bound and propagated throughout the object model source code produced. The goal of this architectural shift is to make it easier to adapt custom forms to a generic data object interface rather than relying on any particular SchemaDef specification.
All 2.4 projects have been remanufactured by MSS Code Factory 2.3.12946 and rebuilt and packaged with the OpenJDK 8 versions of CFLib and CFCore.
The refactored CFTip code has been debugged by running a CFSecurity 2.4 client debug session against a CFDbTest 2.4 server debug session. The only reason two projects need to be used for this process is that Eclipse won't let you open the same project twice, so you can't debug the CFDbTest 2.4 client against a debug session of the same project's server.
All of the 2.4 projects have been remanufactured by MSS Code Factory 2.3.12936.
This is the test suite for MSS Code Factory 2.3.12936 (Production.)
You do not get to take over the copyright and re-license code as you see fit when you incorporate an existing project's model into your project. For example, the Apache licensed code fragments and files associated with the CFSecurity model remain under the Apache license, not your project's license. Similarly, the copyright period and copyright holder retain their original identifications. The project banner does, however, change to the description of your project.
The CFSecurity, CFInternet, and CFCrm 2.4 projects have been re-licensed under the Apache V2 license, as the BSD 3-Clause turns out to be incompatible with GPLv3 code. Apache V2 is still incompatible with GPLv2, so you may not derive GPLv2 projects from CFSecurity 2.4, which means you can't use MSS Code Factory for GPLv2 projects.
The BSD-3Clause attributions have been removed from all of the other 2.4 projects. The CFAcc, CFAsterisk, CFDbTest, CFEnSyntax, and CFFreeSwitch projects are under a dual GPLv3/Commercial license, and CFBam is under a triple Eclipse Public License/GPLv3/Commercial license so that CFBam can be used to write modelling user interfaces under Eclipse.
All of the 2.4 projects have been clean compiled and packaged for shipment.
All of the 2.4 projects have been manufactured by MSS Code Factory 2.3.12927 and are ready to be built for packaging and shipping.
This is the test suite for the production release of MSS Code Factory 2.3.