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