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 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>>> > >>> > >>> > >>> > > > > > > >
