beehive-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Feit <>
Subject Re: project structure and the Page Flow compiler
Date Thu, 17 Mar 2005 08:12:31 GMT
Hi Alex,

Thank you for the feedback.  I agree about the classpath -- it's 
actually already on the "build-pageflows" macro of beehive-tools.xml (I 
should have included that in the list below).


Alexander Smirnoff wrote:

> This makes sense a lot in Pollinate. We do not currently support 
> flexible project layouts, but we will eventually in the future.
> In addition to this I would add "extLibDir" and "extClasses" (or even 
> better: "extClasspath") to refernce a classpath classes and libraries 
> from other external 'modules' or projects (like EAR, other Eclipse 
> projects or whatever).
> 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