beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eddie O'Neil <ekon...@gmail.com>
Subject Re: Beehive/tooling issue
Date Fri, 09 Sep 2005 15:48:16 GMT
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 <richfeit@gmail.com> 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 <richfeit@gmail.com> 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 <richfeit@gmail.com> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >
> >
> >
>

Mime
View raw message