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/03/15 22:08:26 UTC
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>.
I see. These all go to the build-pageflows macro. I've added the
updated list (based on feedback from Jeremiah and Eddie) below, with
some notes about how the parameters are used.
- (*) srcdir: the root directory which will be scanned for source
files. This is passed through to the <apt> task.
- (*) classpathref: the classpath reference for building page flows.
This is appended with the path to beehive-netui-compiler.jar, then
passed to <apt>.
- sourcepathref: a path that contains all the source roots. Defaults
to @{srcdir} and @{srcdir}/WEB-INF/src. This is passed to <apt> *and*
is passed to the Page Flow APs as -Aweb.source.roots.
- webcontentdir: the root location for web content (e.g., JSPs,
web.xml, etc.). Defaults to @{srcdir}. This is passed to the Page Flow
APs as -Aweb.content.root.
- 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 @{srcdir}. This is
passed to the Page Flow APs as -Aweb.output.root.
- classoutputdir: the directory for compiled classes. Defaults to
@{weboutputdir}/WEB-INF/classes. This is passed to <apt> as 'destdir'.
- tempdir: the directory for temporary .java files, copied from page
flows (etc.) with non-.java extensions. Defaults to
@{srcdir}/WEB-INF/.tmpbeansrc. This is passed to <apt> as 'gendir'.
Let me know if you have more questions about this.
Rich
Alexander Smirnoff wrote:
> 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...
>
> Alex.
>
> 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
>>>>
>>>
>>>
>>
>
>
Re: project structure and the Page Flow compiler
Posted by Alexander Smirnoff <al...@sympatico.ca>.
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...
Alex.
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
>>>
>>
>>
>
Re: project structure and the Page Flow compiler
Posted by Richard Feit <ri...@bea.com>.
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
>>
>
>
Re: project structure and the Page Flow compiler
Posted by Alexander Smirnoff <al...@sympatico.ca>.
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
>
Re: project structure and the Page Flow compiler
Posted by Richard Feit <ri...@bea.com>.
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).
Rich
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
>>
>
>
Re: project structure and the Page Flow compiler
Posted by Alexander Smirnoff <al...@sympatico.ca>.
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
>