Eddie, Good point, InputStream would probably be better. :)
The Beehive ant task takes a fileset of .control.properties files, uses that manifest class to parse them as it builds various mappings, and then calls the Assembler class. I'm assisting with some IDE-driven assembly in Eclipse, and calling the ant task isn't very natural from the IDE. Instead we're calling straight into the Assembler class and need to gather the various mappings to call it with. Also, the various locations of these files are not all in a single directory tree, but possibly scattered across various projects, and the files could also be in jars when using nested controls. So I am doing something similar to what the ant task does, but pulled out off ant-land. The IDE passes in a starter set of .controls.properties directly in a user's app or webapp project, and I use the classpath provided by the IDE to discover any additional .controls.properties files from other projects or in jars. This allows the IDE to not have to work so hard to find all of these files. One other interesting thing on assembly. It would be nice if the assembly framework could somehow be extended to allow an assembler to be specified for specific annotations, instead of only on control implementation classes. This would allow assembly to occur in cases where an annotation might be used on any number of kinds of controls. Regards - Jim. On 10/14/05, Eddie O'Neil <[EMAIL PROTECTED]> wrote: > > Jim-- > > On this specific issue, I'd prefer a constructor that takes an > InputStream as it's a more generalized solution than taking a URL. > But, generally, why can't this just be captured in a specific > assembler that knows the work that it needs to do? Why does it have > to be driven by something that requires the caller to know the files > to open and about InputStreams directly? > > Eddie > > > On 10/14/05, Jim Cummings <[EMAIL PROTECTED]> wrote: > > I am doing some IDE-driven assembly work that requires reading the > control > > client manifest files (*.controls.properties) from various places, > including > > from the classpath. > > > > I then need to read these files and build the control/client mappings to > > send to the standard Beehive assembly process. > > > > I'd like to use the ControlClientManifest class to do the simple parsing > of > > these files, but it does not have a constructor that takes an > InputStream or > > URL, which are my two choices when loading these files from a class > loader. > > > > Anyone opposed to me adding an additional constructor to this that takes > say > > a URL? I'd be glad to open a JIRA issue and submit a patch if there are > no > > objections. > > > > Thanks - Jim. > > > > >
