You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@beehive.apache.org by Richard Feit <ri...@bea.com> on 2005/04/20 06:25:15 UTC

Re: project structure and the Page Flow compiler

Hi all,

This is a month-old thread that I'm resurrecting for update and 
comment.  If you're interested in flexibility of project structure for 
the Page Flow compiler (or if you're interested in the Page Flow 
compiler in general), please speak up with opinions about this.

I have a local change which adds/modifies the following attributes to 
the "build-pageflows" macro in beehive-tools.xml.  (*) means the 
attribute is required.

    - (*) sourceDir: the root directory which will be scanned for source 
files.

    - (*) classpathRef: the classpath reference for building page flows.

    - webContentDir: the root location for web content (e.g., JSPs, 
web.xml, etc.).  Defaults to @{sourceDir}.

    - additionalSourceDirs: a space-separated list of additional source 
roots which fall *under* @{sourceDir}.  Defaults to 
@{sourceDir}/WEB-INF/src.

    - webOutputDir: the root of the webapp build output directory, for 
generated webapp files (e.g., generated Struts config files in 
WEB-INF/.pageflow-struts-generated).  Defaults to @{sourceDir}.

    - classOutputDir: the directory for compiled classes.  Defaults to 
@{webOutputDir}/WEB-INF/classes.

    - tmpDir: the directory for temporary .java files, copied from page 
flows (etc.) with non-.java extensions.  Defaults to 
@{sourceDir}/WEB-INF/.tmpbeansrc.

I *think* this provides enough flexibility for various project 
structures, without jamming in too many required parameters.  Jeremiah 
suggested that even the classpath should have a default value, and it 
does have a default in buildWebapp.xml, but in the more basic 
"build-pageflows" macro, I found it hard to come up with a default value 
since this needs to include "appserver.build.classpath" for things like 
the Servlet APIs.

Any comments/criticisms?

Thanks,
Rich


Richard Feit wrote:

> (Moving this back to the user list -- I shouldn't have cross-posted 
> originally.)
>
> I agree -- this should have been listed as another required attribute 
> below.
>
> Rich
>
> Jeremiah Johnson wrote:
>
>> You didn't specify that classpath is a parameter, but I think that you
>> should list that as currently required.  If possible, it would be nice
>> to have a default of
>> ${outputDir}/WEB-INF/classes:${outputDir}/WEB-INF/lib/*.jar.
>>
>> - jeremiah
>>
>> -----Original Message-----
>> From: Richard Feit Sent: Tuesday, March 15, 2005 2:08 PM
>> To: Beehive Users
>> Cc: Beehive Developers
>> Subject: project structure and the Page Flow compiler
>>
>> 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
>>
>>
>>  
>>
>

Re: project structure and the Page Flow compiler

Posted by Richard Feit <ri...@bea.com>.
CIL...

Eddie O'Neil wrote:

> Rich--
>
>   This is great!  Will be quite helpful to have this flexibility in 
> project layout.
>
>   There seem to be two major web project structures to easily support 
> (and document):
>
> fooWeb/
>   *.jsp, *.jpf
>   ...
>   WEB-INF/
>     src/
>       *.java, *.jpf, *.jcs, etc
>     web.xml
>
> and
>
> fooWeb/
>   web/
>     *.jsp, *.jpf
>     WEB-INF/
>       web.xml
>   src/
>     *.java, *.jcs, etc
>
> In essence, the first is source-in-webapp and the second is 
> source-out-of webapp.  Other project structures are certainly 
> possible, and of course, these build steps can be combined with builds 
> to compile webapp source to JARs in WEB-INF/lib, include external 
> JARs, etc.
>
I agree.  The one permutation on this is that the web output directory 
(the root of the directory that could be packaged into a .war) may or 
may not be the same as fooWeb (source-in-webapp) or fooWeb/web 
(source-out-of-webapp).  I do think we have this covered, though.
   

>   A couple of comments:
>
> - "additionalSourceDirs" -- we're separating other things in the 
> macros (like the list of file extensions for "compileByExtension") 
> with commas.  Probably worth being consistent here.  Also, some OSs 
> allow for spaces in directory names, so it might be worth picking 
> something else we can tokenize.
>
Yeah, the issue is that this gets passed to apt in a comma-separated 
list of options.  I should bite the bullet and add actual subelements to 
Beehive's <apt> ant task -- that would allow the option itself to 
contain commas.

> - it would be a little strange to default the classpath to something. 
> We're not attempting to do that in any other macros (for building 
> controls, XSDs, etc), so it would be inconsistent to default one of 
> them.  And, we're always going to be incomplete even if we do default 
> because some classpath to the Servlet / JSP APIs will still need to be 
> passed in as that will vary by app server.  I agree with you that 
> leaving the macros as just tools and then building classpath / module 
> build support atop them is the right way to go.
>
Cool, thanks for confirming my uneducated guess.  :)  And thanks for the 
feedback.

Rich

> Eddie
>
>
>
>
>
>
> Richard Feit wrote:
>
>> Hi all,
>>
>> This is a month-old thread that I'm resurrecting for update and 
>> comment.  If you're interested in flexibility of project structure 
>> for the Page Flow compiler (or if you're interested in the Page Flow 
>> compiler in general), please speak up with opinions about this.
>>
>> I have a local change which adds/modifies the following attributes to 
>> the "build-pageflows" macro in beehive-tools.xml.  (*) means the 
>> attribute is required.
>>
>>    - (*) sourceDir: the root directory which will be scanned for 
>> source files.
>>
>>    - (*) classpathRef: the classpath reference for building page flows.
>>
>>    - webContentDir: the root location for web content (e.g., JSPs, 
>> web.xml, etc.).  Defaults to @{sourceDir}.
>>
>>    - additionalSourceDirs: a space-separated list of additional 
>> source roots which fall *under* @{sourceDir}.  Defaults to 
>> @{sourceDir}/WEB-INF/src.
>>
>>    - webOutputDir: the root of the webapp build output directory, for 
>> generated webapp files (e.g., generated Struts config files in 
>> WEB-INF/.pageflow-struts-generated).  Defaults to @{sourceDir}.
>>
>>    - classOutputDir: the directory for compiled classes.  Defaults to 
>> @{webOutputDir}/WEB-INF/classes.
>>
>>    - tmpDir: the directory for temporary .java files, copied from 
>> page flows (etc.) with non-.java extensions.  Defaults to 
>> @{sourceDir}/WEB-INF/.tmpbeansrc.
>>
>> I *think* this provides enough flexibility for various project 
>> structures, without jamming in too many required parameters.  
>> Jeremiah suggested that even the classpath should have a default 
>> value, and it does have a default in buildWebapp.xml, but in the more 
>> basic "build-pageflows" macro, I found it hard to come up with a 
>> default value since this needs to include "appserver.build.classpath" 
>> for things like the Servlet APIs.
>>
>> Any comments/criticisms?
>>
>> Thanks,
>> Rich
>>
>>
>> Richard Feit wrote:
>>
>>> (Moving this back to the user list -- I shouldn't have cross-posted 
>>> originally.)
>>>
>>> I agree -- this should have been listed as another required 
>>> attribute below.
>>>
>>> Rich
>>>
>>> Jeremiah Johnson wrote:
>>>
>>>> You didn't specify that classpath is a parameter, but I think that you
>>>> should list that as currently required.  If possible, it would be nice
>>>> to have a default of
>>>> ${outputDir}/WEB-INF/classes:${outputDir}/WEB-INF/lib/*.jar.
>>>>
>>>> - jeremiah
>>>>
>>>> -----Original Message-----
>>>> From: Richard Feit Sent: Tuesday, March 15, 2005 2:08 PM
>>>> To: Beehive Users
>>>> Cc: Beehive Developers
>>>> Subject: project structure and the Page Flow compiler
>>>>
>>>> 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
>>>>
>>>>
>>>>  
>>>>
>>>
>>
>
>

Re: project structure and the Page Flow compiler

Posted by Eddie O'Neil <ek...@bea.com>.
Rich--

   This is great!  Will be quite helpful to have this flexibility in 
project layout.

   There seem to be two major web project structures to easily support 
(and document):

fooWeb/
   *.jsp, *.jpf
   ...
   WEB-INF/
     src/
       *.java, *.jpf, *.jcs, etc
     web.xml

and

fooWeb/
   web/
     *.jsp, *.jpf
     WEB-INF/
       web.xml
   src/
     *.java, *.jcs, etc

In essence, the first is source-in-webapp and the second is 
source-out-of webapp.  Other project structures are certainly possible, 
and of course, these build steps can be combined with builds to compile 
webapp source to JARs in WEB-INF/lib, include external JARs, etc.

   A couple of comments:

- "additionalSourceDirs" -- we're separating other things in the macros 
(like the list of file extensions for "compileByExtension") with commas. 
  Probably worth being consistent here.  Also, some OSs allow for spaces 
in directory names, so it might be worth picking something else we can 
tokenize.

- it would be a little strange to default the classpath to something. 
We're not attempting to do that in any other macros (for building 
controls, XSDs, etc), so it would be inconsistent to default one of 
them.  And, we're always going to be incomplete even if we do default 
because some classpath to the Servlet / JSP APIs will still need to be 
passed in as that will vary by app server.  I agree with you that 
leaving the macros as just tools and then building classpath / module 
build support atop them is the right way to go.

Eddie






Richard Feit wrote:
> Hi all,
> 
> This is a month-old thread that I'm resurrecting for update and 
> comment.  If you're interested in flexibility of project structure for 
> the Page Flow compiler (or if you're interested in the Page Flow 
> compiler in general), please speak up with opinions about this.
> 
> I have a local change which adds/modifies the following attributes to 
> the "build-pageflows" macro in beehive-tools.xml.  (*) means the 
> attribute is required.
> 
>    - (*) sourceDir: the root directory which will be scanned for source 
> files.
> 
>    - (*) classpathRef: the classpath reference for building page flows.
> 
>    - webContentDir: the root location for web content (e.g., JSPs, 
> web.xml, etc.).  Defaults to @{sourceDir}.
> 
>    - additionalSourceDirs: a space-separated list of additional source 
> roots which fall *under* @{sourceDir}.  Defaults to 
> @{sourceDir}/WEB-INF/src.
> 
>    - webOutputDir: the root of the webapp build output directory, for 
> generated webapp files (e.g., generated Struts config files in 
> WEB-INF/.pageflow-struts-generated).  Defaults to @{sourceDir}.
> 
>    - classOutputDir: the directory for compiled classes.  Defaults to 
> @{webOutputDir}/WEB-INF/classes.
> 
>    - tmpDir: the directory for temporary .java files, copied from page 
> flows (etc.) with non-.java extensions.  Defaults to 
> @{sourceDir}/WEB-INF/.tmpbeansrc.
> 
> I *think* this provides enough flexibility for various project 
> structures, without jamming in too many required parameters.  Jeremiah 
> suggested that even the classpath should have a default value, and it 
> does have a default in buildWebapp.xml, but in the more basic 
> "build-pageflows" macro, I found it hard to come up with a default value 
> since this needs to include "appserver.build.classpath" for things like 
> the Servlet APIs.
> 
> Any comments/criticisms?
> 
> Thanks,
> Rich
> 
> 
> Richard Feit wrote:
> 
>> (Moving this back to the user list -- I shouldn't have cross-posted 
>> originally.)
>>
>> I agree -- this should have been listed as another required attribute 
>> below.
>>
>> Rich
>>
>> Jeremiah Johnson wrote:
>>
>>> You didn't specify that classpath is a parameter, but I think that you
>>> should list that as currently required.  If possible, it would be nice
>>> to have a default of
>>> ${outputDir}/WEB-INF/classes:${outputDir}/WEB-INF/lib/*.jar.
>>>
>>> - jeremiah
>>>
>>> -----Original Message-----
>>> From: Richard Feit Sent: Tuesday, March 15, 2005 2:08 PM
>>> To: Beehive Users
>>> Cc: Beehive Developers
>>> Subject: project structure and the Page Flow compiler
>>>
>>> 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
>>>
>>>
>>>  
>>>
>>
>