Sounds good -- will do. Rich Eddie O'Neil wrote:
> Yeah -- that would work. I always run that target in a clean sync, >so I don't tend to see SVN version numbers that reflect local changes. > Feel free to just add that to the block that determines the version. > >Eddie > > > >On 9/9/05, Rich Feit <[EMAIL PROTECTED]> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > >
