One other thing here. Jim Cummings has pointed out that this eliminates the need for the "weboutputdir" attribute on the <build-pageflows> macro, as well as the "web.output.root" option for our annotation processors. I'd like to deprecate the "weboutputdir" attribute, and remove the "web.output.root" option. Any thoughts/objections?
Rich Rich Feit wrote: >OK, great. Thanks for taking a look at it so quickly. > >Does anyone have any opposition to this fix getting checked in? > >Also, one quick thing: the nightly-test script failed on my Windows box >because it tried to create a directory with ':' in it: > build\dist\apache-beehive-20050909-svn279336:279683M > >I think all we need to do is filter the output of 'svnversion' in >nightly.xml, to replace the ':' with something else. Does that make sense? > >Rich > >Eddie O'Neil wrote: > > > >>Rich-- >> >> The diff looks good -- making this change definitely makes the >>webapp build process simpler as it removes another tmp directory to >>clean / manage. >> >> Nice... >> >>Eddie >> >> >> >>On 9/9/05, Rich Feit <[EMAIL PROTECTED]> wrote: >> >> >> >> >>>Ah, that's great. I'd been doing a build.dist.full, then running a >>>script to expand the dists and run tests against them. This is nicer. :) >>> >>>Rich >>> >>>Eddie O'Neil wrote: >>> >>> >>> >>> >>> >>>>You can run a full-on distribution test run by: >>>> >>>>cd trunk/ant >>>>ant -f nightly.xml run >>>> >>>>It should run end-to-end without any trouble, though there are >>>>occasionally intermittant failures during controls testing on Linux. >>>> >>>>Eddie >>>> >>>> >>>> >>>>On 9/9/05, Rich Feit <[EMAIL PROTECTED]> wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>>>That's great, thanks -- hopefully there'll be agreement on this. FYI, >>>>>this passes tests in the tree (will be important to test against the >>>>>distributions though). >>>>> >>>>>Anyone else have comments about this? >>>>> >>>>>Rich >>>>> >>>>>Eddie O'Neil wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>I'd fix it too. :) It makes sense to have the generated >>>>>>struts-config files end up in WEB-INF/classes because they're really >>>>>>not meant to be read / write configuration files (like web.xml or >>>>>>beehive-netui-config.xml). >>>>>> >>>>>>Also, better to ship 1.0 without having to change the behavior later. >>>>>> >>>>>>Will take a look over the patch... >>>>>> >>>>>>Eddie >>>>>> >>>>>> >>>>>>On 9/9/05, Rich Feit <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>OK, I've added a patch for this in the bug. Feel free to give it a good >>>>>>>once-over. >>>>>>> >>>>>>>I'm running tests now -- looks OK so far. The only ill effect of this >>>>>>>change is one which would only get worse over time (the longer we wait >>>>>>>to do it): for *legacy* apps, where the root Struts-config file path is >>>>>>>specified in web.xml, we can no longer honor that path when we generate >>>>>>>the file. In these apps, you will get an error logged at Servlet >>>>>>>startup about Struts not being able to load the file (though everything >>>>>>>does work fine). >>>>>>> >>>>>>>Rich >>>>>>> >>>>>>>Rich Feit wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Hi all, >>>>>>>> >>>>>>>>I just entered http://issues.apache.org/jira/browse/BEEHIVE-915 : Page >>>>>>>>Flow annotation processors generate files in an IDE-unfriendly way. It >>>>>>>>turns out that the way we generate files when running under apt works >>>>>>>>fine on the command line, but makes it hard for an IDE (implementing the >>>>>>>>Mirror interfaces) to know when/where our generated files are created. >>>>>>>> >>>>>>>>This from the bug: >>>>>>>> >>>>>>>>"Unfortunately, [apt's] Filer offers only two choices of places to >>>>>>>>create files: the source directory and the build directory. This means >>>>>>>>that to fix this bug, our generated files need to move out of WEB-INF, >>>>>>>>into WEB-INF/classes, i.e., they will not only be generated into a >>>>>>>>different place, but they will be read through a different mechanism in >>>>>>>>the runtime." >>>>>>>> >>>>>>>>So, this is definitely not a trivial change. I am working on the fix >>>>>>>>for this, and I'd like to have the discussion about whether to get it >>>>>>>>into v1.0. If we don't, v1.0 won't be toolable in an IDE. >>>>>>>>Additionally, it could cause back-compat problems between this and the >>>>>>>>next version, if people begin to depend on our current location for >>>>>>>>generated files. On the other hand, it's a risky change in that we >>>>>>>>don't have a lot of time to have people hammer on this. The one saving >>>>>>>>grace is that the file location is so fundamental that presumably, any >>>>>>>>bug would cause blatantly bad behavior across the framework. >>>>>>>> >>>>>>>>Let me know what you think. >>>>>>>> >>>>>>>>Thanks, >>>>>>>>Rich >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >> >> >> >> > > >
