beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Cummings <>
Subject Re: new constructor in ControlClientManifest?
Date Fri, 14 Oct 2005 16:44:06 GMT

Good point, InputStream would probably be better. :)

The Beehive ant task takes a fileset of 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 directly in a user's app or webapp
project, and I use the classpath provided by the IDE to discover any
additional 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 <> 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 <> wrote:
> > I am doing some IDE-driven assembly work that requires reading the
> control
> > client manifest files (* 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.
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message