Peter Donald wrote: >>An idea... >> >...snip... > >That is very close to our original design - originally XML was meant to be >only one option (and something that is used only rarely). > >However pure xml files have several advantages. The essential one being that >you don't have to construct a classloader and resolve all the classes to just >read the infos. It would also be cumbersome to represent things like XSchema >in .java files (when we eventually get around to implementing config >validation). Besides it makes for a faster dev cycle based on experience with >BeanInfos (what this spec was originally based upon) and articles like that >declative vs procedural one. >
The "classloader construct" is key I guess. OK I'm convinced. >>The though is that as XML blocks go, the xinfo is fairly mundane. If >>these were Java classes, they could be more visible to those perusing >>the Java source of a thing. Half of our Phoenix newbie issues are >>because people are not keeping their xinfo files in step with their >>assembly.xml files. With advanced IDEs like Intellij it will hopefully >>ripple changes through to this BlockDef class as people iteratively >>rename their chosen demo/pdk starting point to become their server app. >> > >That is a problem. There was a few things we can do to alleviate this issue. >We could allow some sort of automagic creation of .xinfo files from javadocs >of specified blocks. This would help keep cost of maaintaining them down a >bit. > Value points = 1 >We could also (finally) create ant tasks to run the verifier over .sars >before they are deployed. This should give a good indication whether the >format is valid. > Value points = 2 >We could also create DTDs for the different formats as appropriate and >interpret > VP = 1 >the files with that mind. > >I could also write a "Block File Archive Verifier" that verified the format >of all the Blocks info files, and the relationship beteen services inside the >jar, the manifest entrtys and so forth. > VP = 4. Something that owuld comprehensively tell you what is wrong with a SAR. Something that we might not want part of the regular Phoenix machine (which we are trying to keep lean?) - Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
