i need a local markdown parser so i can test this stuff without pushing a thousand times :D
this is, at the moment, a test facility. The server test rule will get an operation to generate an open port for the local machine, start the server bound to that port, and potentially configure a web driver rule to talk to that binding.
integration testing is now its own project. or rather, again. the test server rule can now start http. pending: integrations with the web driver rule the web driver rule now has the beginnings of a page object system. more to come! some attendant changes in the kernel to support this change, particularly in how the resource resolver works. we now have three running modes, the full packaged installation, the unpackaged unit test execution, and the packaged integration test execution TODO: make a new task for a smoke test, update CI to run it
this is a combination of several changes, roughly explained below. the changelist is huge, I know making components to represent the application structure beginning to propagate the app location through the resource system pushing the Application system one layer higher. along the way, replaced a silly test with a smarter one abstracted the notion of application path resolution from the resource system cleaned up the css resource handling of uris that i broke. whoops okay, the system is stable sourcing its directories from the Application - multiplexed lookups! - asset restructuring must continue. delete the AssetResource and associated integration testing for the file watch service. now it can be refactored splitting the watch service into chunks, and isolating the piece of the JDK that is hard to mock things are being tested! shuffling around IO execution to its rightful place about to start making IO tasks wait upon each other instead of scribbling all over each other's fine work for naught. the current solution was working correctly for concurrency purposes, but it's fairly inefficient now that document requests (and possibly soon others) can initialize script environments directly. basically we end up initializing enough document script environments to fill the IO executor, and then throwing all but one out when this was just file resources, i could live with it, but i want script initialization to be idempotent, and the most correct way is to synch up in the resource finder when a creation is under contention some documentation and rearranging, mainly for comprehension resource creation is now a synchronization point first one through the gate does the creation job, other threads wait until it is finished and pick up the work excising the asset resource fixing a small bug - return undefined when getting a null result back from the client, since null is a sentinel asset system is gone, replaced with a lookup priority system.
…et of components
…xecution system. it works!
…ystem. now fully plugged in
… by extending the execution system. yay APIs