beehive-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Smirnoff <>
Subject Re: project structure and the Page Flow compiler
Date Thu, 21 Apr 2005 17:35:53 GMT
Almost... The compiler parameters you discussing here - where they go 
to: macro definition or AptTask? Or both? Or there is something else?

In Pollinate we want to be as close as possible to Beehive compilation 
process. So reusing AptTask inside Eclipse can be one of the solutions. 
Currently we just running APT tool from within Eclipse. I'm trying to 
provide the solution of reusing Beehive's AptTask and currently 
experimenting with it. So if you're adding parameters and flexible 
layout to Ant's macros we will have to emulate the same thing in 
Pollinate Builder, however if you're extending AptTask to do that, then 
the support will be available for us right out off the box...


Richard Feit wrote:

> Good question -- it's really the annotation processor(s) (which gets 
> launched through "build-pageflows" and through AptTask).  
> Specifically, it's the AnnotationProcessors that are chosen by the 
> factories 
> org.apache.beehive.netui.compiler.apt.PageFlowAnnotationProcessorFactory 
> and 
> org.apache.beehive.netui.compiler.apt.FormBeanAnnotationProcessorFactory.  
> Is that what you were wondering?
> Rich
> Alexander Smirnoff wrote:
>> Richard,
>> When you say 'compiler' do you mean 
>> "org.apache.beehive.controls.runtime.generator.AptTask" class or 
>> you're talking about 'build-pageflows' macro? Sorry I missed this 
>> from the beginning and just want to be sure for 100%.
>> Thanks,
>> Alex.
>> Richard Feit wrote:
>>> Hi all,
>>> Currently, the Page Flow compiler assumes that your entire webapp is 
>>> in one place: source, resources, config files, build output, etc.  
>>> It infers the root of the webapp by crawling up from the current 
>>> source file and looking for WEB-INF/web.xml.  This is obviously 
>>> broken for many (most?) project structures.  Eddie and I had an 
>>> email conversation about this, and came up with a number of 
>>> parameters you'd want to be able to specify:
>>>    1) [required] srcDir: the root for source files in your webapp 
>>> (*.java, etc.)
>>>    2) [required] outputDir: the root of the *built* webapp (the 
>>> directory that could turn into a .war)
>>>    3) [required] contentDir: the root for web content files (all 
>>> web-addressable files: *.jsp, *.html, etc.)
>>>    4) [optional] webinfDir: the source WEB-INF directory.  
>>> *optional: defaults to ${contentDir}/WEB-INF
>>>    5) [optional] tmpDir: the temporary directory for generated 
>>> source files.  *optional: defaults to ${outputDir}/WEB-INF/.tmpbeansrc
>>> You could of course set (1), (2), and (3) to the same thing to make 
>>> the compiler act like it does today.
>>> Thoughts?  Does anyone have a project structure for which this 
>>> doesn't work?  Are any of (1), (2), (3) fundamentally unnecessary?
>>> Thanks,
>>> Rich

View raw message