On Thursday 25 September 2003 00:50, Stephen McConnell wrote: > Niclas Hedhman wrote: > >I just wanted to highlight that my notion of component is a much tighter > >entity, something like a black box with a known set of interfaces, to > > which it has to adhere. NOW, those interfaces are pretty loose, and I > > would like to see a stricter contract. > > How close are you to something you can propose/talk about kick-around?
It was all done for Phoenix, and is now slowly (very!) transferred over to Merlin... The "DevKit" recognizes 3 stages, Block Specification, Block Implementation and Projects (you would call it deployments). DevKit Installation ============== The DevKit ask a dozen questions about the user, company, package names, where development is located and central repository (provided by me typically). Block Specification ============== 1. An ANT script asks for a name, a Service interface creates a full directory structure, creates the Service interface and the skeleton for a web based UI and documentation (xdocs). 2. After the first step, the spec is compilable and "operational". 3. User adds the java code and documentation. 4. User creates a expected XML representation of objects part of the specification, and uses them as templates for creating the UI parts, transformations for SVG, HTML and WML. 5. User runs ANT, and a Block Spec tarball is created, complete with the Jar files, the documentation (both HTML and XDocs) and UI parts. 6. (Not ready yet), the tarball is optionally published on central repository. Block Implementation ================ 1. A similar ANT script asks for a name, the Service interface to implement and the name of the Service implementation class, and creates the implementation class directory structures. 2. User copies the Block Spec tarball to the "spec/" directory. 3. User does the implementation and documentation. Also default configurations are made. 4. User can add additional UI parts, which "extend" beyond the specification requirement. 5. The ant script merges the spec and the impl, Xdocs wise, source code wise and UI wise, into a single tarball. 6. (not done) The implementation can be published on central repository. Project / Deployment ================ 1. Ant script creates directory structure, and skeleton environment.xml, assembly.xml. 2. User copies in all the block implementation tarballs to use, into "impl/" directory. 3. First run of Ant extracts and merges configurations, xdocs sitemap, and the UI stuff. The user creates the assembly.xml (not done for Merlin yet). 4. Ant creates the SAR and WAR files respectively. The WAR file is a Cocoon serving both the xdocs as well as the "real-time view" of the SAR application. 5. (not done) The project can be published. (not gotten too far in the "project" area before starting to work on the Merlin transition. In the above, there are also unit testing, UI testing and testing in container. The idea of generating the HTML docs and making them part of each tarball is that they can be directly read without Cocoon or Forrest. xdocs are distributed so they can be merged into a single site. The formats of the tarballs are only optimized for "merging" activites in subsequent steps, and are far from "nice" in layout. Since I don't use any Ant Tasks or other scripts, everything is done with copy, there are a lot of things to be put in the correct places. The Ant script for each stage is referring to a global ant script, and people are not allowed to mess around with the properties, or I won't guarantee it works (=restrictions). Does this give an overview? Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
