Mailing-List: contact dev-help@beehive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Beehive Developers" <dev@beehive.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of ekoneil@gmail.com designates
 64.233.184.196 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Ha056UtrK9sozytxG3HKCcZ6+/Hti3RVTWdMzBHbHmV2C63yDPOQohllxsjPciDg1YwhJuO6goPv27rtQyfwNsyJ34DhDjbLzBwU6VoIr26c9AKvitLebnQKSsxTgPU0DQX2HM1eKreOc1UbJLJz8lrGs73H5UVjLwhdDYkwE5k=
Message-ID: <e9ac8354050909084831a9165@mail.gmail.com>
Date: Fri, 9 Sep 2005 09:48:16 -0600
From: Eddie O'Neil <ekoneil@gmail.com>
Reply-To: ekoneil@gmail.com
To: Beehive Developers <dev@beehive.apache.org>
Subject: Re: Beehive/tooling issue
In-Reply-To: <4321A5B3.7040201@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <43212697.5060801@gmail.com> <4321512E.7060309@gmail.com>
	 <e9ac83540509090650dfe6a4b@mail.gmail.com>
	 <43219E7F.2060004@gmail.com>
	 <e9ac835405090907584f6e226@mail.gmail.com>
	 <4321A5B3.7040201@gmail.com>

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.  :=
)
>=20
> Rich
>=20
> Eddie O'Neil wrote:
>=20
> >  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 g=
ood
> >>>>once-over.
> >>>>
> >>>>I'm running tests now -- looks OK so far.  The only ill effect of thi=
s
> >>>>change is one which would only get worse over time (the longer we wai=
t
> >>>>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 genera=
te
> >>>>the file.  In these apps, you will get an error logged at Servlet
> >>>>startup about Struts not being able to load the file (though everythi=
ng
> >>>>does work fine).
> >>>>
> >>>>Rich
> >>>>
> >>>>Rich Feit wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Hi all,
> >>>>>
> >>>>>I just entered http://issues.apache.org/jira/browse/BEEHIVE-915 : Pa=
ge
> >>>>>Flow annotation processors generate files in an IDE-unfriendly way. =
 It
> >>>>>turns out that the way we generate files when running under apt work=
s
> >>>>>fine on the command line, but makes it hard for an IDE (implementing=
 the
> >>>>>Mirror interfaces) to know when/where our generated files are create=
d.
> >>>>>
> >>>>>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 mea=
ns
> >>>>>that to fix this bug, our generated files need to move out of WEB-IN=
F,
> >>>>>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 fi=
x
> >>>>>for this, and I'd like to have the discussion about whether to get i=
t
> >>>>>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 t=
he
> >>>>>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 sav=
ing
> >>>>>grace is that the file location is so fundamental that presumably, a=
ny
> >>>>>bug would cause blatantly bad behavior across the framework.
> >>>>>
> >>>>>Let me know what you think.
> >>>>>
> >>>>>Thanks,
> >>>>>Rich
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >
> >
> >
>