You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-user@jakarta.apache.org by Erik Hatcher <li...@ehatchersolutions.com> on 2001/11/02 11:14:35 UTC
conditional building of Cactus deployments
Where can I find good examples of how folks are architecting their Ant
builds such that a release version is built without any test code in it
whatsoever and when the tests are run the deployment is built to include the
necessary pieces for Cactus testing?
Here are the issues I'm facing:
* Some tests are non-Cactus JUnit tests. Some are Cactus. I'm separating
them by directory structure. There needs to be a distinction in the Ant
targets on which tests get run and such.
* web.xml allow conditional inclusion of the redirector configuration
* I do not want duplication in my build.xml
I'm going to start tackling these issues myself, but if its already been
implemented nicely then it'd save me some time and I'd be able to contribute
my efforts on the Cactus project in other areas! :)
Erik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Cactus FAQ (Was Re: conditional building of Cactus deployments)
Posted by Vincent Massol <vm...@octo.com>.
Yes, Nick, I tend to agree with you. I have indeed sent a mail a week ago to
the jakarta general mailing list asking what the "jakarta way" in regards to
FAQs. I asked if the recommended way Jyve, a file withing each project or
jguru. Unfortunately I got no response. I'm posting a new message now. We'll
see
Thanks
-Vincent
----- Original Message -----
From: "Nicholas Lesiecki" <ni...@eblox.com>
To: "Cactus Users List" <ca...@jakarta.apache.org>
Sent: Friday, November 09, 2001 6:24 PM
Subject: RE: conditional building of Cactus deployments
> I'd rather have just on FAQ--but I'm not too concerned. It might make
sense
> to have that on FAQ on JGuru and link out to it from Cactus' website. That
> way we could leverage JGuru's search facilities and get more press for
> Cactus. Also, if their FAQ mangement system is better than manually
> re-building the site with new xml files, that would probably save us som e
> time and improve FAQ responsiveness.
>
> So I vote moving the FAQ to JGuru entirely.
>
> Any thoughts?
>
> Nick
>
> -----Original Message-----
> From: Erik Hatcher [mailto:lists@ehatchersolutions.com]
> Sent: Thursday, November 08, 2001 7:38 PM
> To: Cactus Users List; Vincent Massol
> Subject: Re: conditional building of Cactus deployments
>
>
> I got somewhat a somewhat cold reception by the ant-dev crew for the Ant
FAQ
> at jGuru as there is already an Ant FAQ on the official Jakarta site and
> some folks view it as one more channel that would overload already
> overloaded folks because they monitor ant-user and ant-dev, and to monitor
> one more forum is just too many avenues for support.
>
> All reasonable concerns. I just wanted to make you aware of some pushback
I
> received.
>
> But have you tried jGuru's search engine? Its literally the best dang
Java
> search engine available (and if anyone knows of one better let me know).
If
> jGuru and Jakarta could team up to work together on an FAQ system it would
> be fantastic. jGuru already "brands" their site for folks outsourcing to
> them, and the top folks at jGuru really want to be tight with Jakarta.
I'm
> not sure of the underlying legalities or arrangements that would need to
be
> made - and I'm sure there are some issues that would need to be ironed out
> by ASF.
>
> But for now there is a Ant, Lucene, and Struts Forum and FAQ there.
(maybe
> other Jakarta ones?)
>
> Erik
>
>
>
> ----- Original Message -----
> From: "Vincent Massol" <vm...@octo.com>
> To: "Erik Hatcher" <li...@ehatchersolutions.com>;
> <ca...@jakarta.apache.org>
> Sent: Thursday, November 08, 2001 5:07 PM
> Subject: Re: conditional building of Cactus deployments
>
>
> >
> >
> > ----- Original Message -----
> > From: "Erik Hatcher" <li...@ehatchersolutions.com>
> > To: "Cactus Users List" <ca...@jakarta.apache.org>; "Vincent
Massol"
> > <vm...@octo.com>
> > Sent: Tuesday, November 06, 2001 12:33 AM
> > Subject: Re: conditional building of Cactus deployments
> >
> >
> > > Well.... I *am* the Ant jGuru afterall! :))
> > >
> > > http://www.jguru.com/faq/Ant
> > >
> > > Actually that brings up a point.... some Cactus expert should lobby
the
> > > jGuru folks for their own FAQ there. I'll make the appropriate
contacts
> > for
> > > anyone interested.
> >
> > why not ? What do other think ?
> >
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: conditional building of Cactus deployments
Posted by Nicholas Lesiecki <ni...@eblox.com>.
I'd rather have just on FAQ--but I'm not too concerned. It might make sense
to have that on FAQ on JGuru and link out to it from Cactus' website. That
way we could leverage JGuru's search facilities and get more press for
Cactus. Also, if their FAQ mangement system is better than manually
re-building the site with new xml files, that would probably save us som e
time and improve FAQ responsiveness.
So I vote moving the FAQ to JGuru entirely.
Any thoughts?
Nick
-----Original Message-----
From: Erik Hatcher [mailto:lists@ehatchersolutions.com]
Sent: Thursday, November 08, 2001 7:38 PM
To: Cactus Users List; Vincent Massol
Subject: Re: conditional building of Cactus deployments
I got somewhat a somewhat cold reception by the ant-dev crew for the Ant FAQ
at jGuru as there is already an Ant FAQ on the official Jakarta site and
some folks view it as one more channel that would overload already
overloaded folks because they monitor ant-user and ant-dev, and to monitor
one more forum is just too many avenues for support.
All reasonable concerns. I just wanted to make you aware of some pushback I
received.
But have you tried jGuru's search engine? Its literally the best dang Java
search engine available (and if anyone knows of one better let me know). If
jGuru and Jakarta could team up to work together on an FAQ system it would
be fantastic. jGuru already "brands" their site for folks outsourcing to
them, and the top folks at jGuru really want to be tight with Jakarta. I'm
not sure of the underlying legalities or arrangements that would need to be
made - and I'm sure there are some issues that would need to be ironed out
by ASF.
But for now there is a Ant, Lucene, and Struts Forum and FAQ there. (maybe
other Jakarta ones?)
Erik
----- Original Message -----
From: "Vincent Massol" <vm...@octo.com>
To: "Erik Hatcher" <li...@ehatchersolutions.com>;
<ca...@jakarta.apache.org>
Sent: Thursday, November 08, 2001 5:07 PM
Subject: Re: conditional building of Cactus deployments
>
>
> ----- Original Message -----
> From: "Erik Hatcher" <li...@ehatchersolutions.com>
> To: "Cactus Users List" <ca...@jakarta.apache.org>; "Vincent Massol"
> <vm...@octo.com>
> Sent: Tuesday, November 06, 2001 12:33 AM
> Subject: Re: conditional building of Cactus deployments
>
>
> > Well.... I *am* the Ant jGuru afterall! :))
> >
> > http://www.jguru.com/faq/Ant
> >
> > Actually that brings up a point.... some Cactus expert should lobby the
> > jGuru folks for their own FAQ there. I'll make the appropriate contacts
> for
> > anyone interested.
>
> why not ? What do other think ?
>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: conditional building of Cactus deployments
Posted by Erik Hatcher <li...@ehatchersolutions.com>.
I got somewhat a somewhat cold reception by the ant-dev crew for the Ant FAQ
at jGuru as there is already an Ant FAQ on the official Jakarta site and
some folks view it as one more channel that would overload already
overloaded folks because they monitor ant-user and ant-dev, and to monitor
one more forum is just too many avenues for support.
All reasonable concerns. I just wanted to make you aware of some pushback I
received.
But have you tried jGuru's search engine? Its literally the best dang Java
search engine available (and if anyone knows of one better let me know). If
jGuru and Jakarta could team up to work together on an FAQ system it would
be fantastic. jGuru already "brands" their site for folks outsourcing to
them, and the top folks at jGuru really want to be tight with Jakarta. I'm
not sure of the underlying legalities or arrangements that would need to be
made - and I'm sure there are some issues that would need to be ironed out
by ASF.
But for now there is a Ant, Lucene, and Struts Forum and FAQ there. (maybe
other Jakarta ones?)
Erik
----- Original Message -----
From: "Vincent Massol" <vm...@octo.com>
To: "Erik Hatcher" <li...@ehatchersolutions.com>;
<ca...@jakarta.apache.org>
Sent: Thursday, November 08, 2001 5:07 PM
Subject: Re: conditional building of Cactus deployments
>
>
> ----- Original Message -----
> From: "Erik Hatcher" <li...@ehatchersolutions.com>
> To: "Cactus Users List" <ca...@jakarta.apache.org>; "Vincent Massol"
> <vm...@octo.com>
> Sent: Tuesday, November 06, 2001 12:33 AM
> Subject: Re: conditional building of Cactus deployments
>
>
> > Well.... I *am* the Ant jGuru afterall! :))
> >
> > http://www.jguru.com/faq/Ant
> >
> > Actually that brings up a point.... some Cactus expert should lobby the
> > jGuru folks for their own FAQ there. I'll make the appropriate contacts
> for
> > anyone interested.
>
> why not ? What do other think ?
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: conditional building of Cactus deployments
Posted by Vincent Massol <vm...@octo.com>.
----- Original Message -----
From: "Erik Hatcher" <li...@ehatchersolutions.com>
To: "Cactus Users List" <ca...@jakarta.apache.org>; "Vincent Massol"
<vm...@octo.com>
Sent: Tuesday, November 06, 2001 12:33 AM
Subject: Re: conditional building of Cactus deployments
> Well.... I *am* the Ant jGuru afterall! :))
>
> http://www.jguru.com/faq/Ant
>
> Actually that brings up a point.... some Cactus expert should lobby the
> jGuru folks for their own FAQ there. I'll make the appropriate contacts
for
> anyone interested.
why not ? What do other think ?
>
> Erik
>
> ----- Original Message -----
> From: "Vincent Massol" <vm...@octo.com>
> To: "Cactus Users List" <ca...@jakarta.apache.org>
> Sent: Monday, November 05, 2001 4:37 PM
> Subject: Re: conditional building of Cactus deployments
>
>
> > Nice work Erik ! I did not know about the filterset task and the
> filtersfile
> > (only knew about the simple filter task)... which accounts for my
answers
> > saying that it would be difficult to implement it with filters ... :)
> >
> > Seems to be a nice and easy solution. I'll add it as a FAQ entry.
> >
> > Thanks
> > -Vincent
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: conditional building of Cactus deployments
Posted by Erik Hatcher <li...@ehatchersolutions.com>.
Well.... I *am* the Ant jGuru afterall! :))
http://www.jguru.com/faq/Ant
Actually that brings up a point.... some Cactus expert should lobby the
jGuru folks for their own FAQ there. I'll make the appropriate contacts for
anyone interested.
Erik
----- Original Message -----
From: "Vincent Massol" <vm...@octo.com>
To: "Cactus Users List" <ca...@jakarta.apache.org>
Sent: Monday, November 05, 2001 4:37 PM
Subject: Re: conditional building of Cactus deployments
> Nice work Erik ! I did not know about the filterset task and the
filtersfile
> (only knew about the simple filter task)... which accounts for my answers
> saying that it would be difficult to implement it with filters ... :)
>
> Seems to be a nice and easy solution. I'll add it as a FAQ entry.
>
> Thanks
> -Vincent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: conditional building of Cactus deployments
Posted by Vincent Massol <vm...@octo.com>.
Nice work Erik ! I did not know about the filterset task and the filtersfile
(only knew about the simple filter task)... which accounts for my answers
saying that it would be difficult to implement it with filters ... :)
Seems to be a nice and easy solution. I'll add it as a FAQ entry.
Thanks
-Vincent
----- Original Message -----
From: "Erik Hatcher" <li...@ehatchersolutions.com>
To: "Cactus Users List" <ca...@jakarta.apache.org>
Sent: Monday, November 05, 2001 6:40 PM
Subject: Re: conditional building of Cactus deployments
> Just for everyone's benefit, here's how I accomplished conditional
inclusion
> of Cactus web.xml configuration. My web.xml file is capable of working
> standalone without requiring any filtered copy to work. In Ant I'm doing
> this:
>
> <!-- Activate the Cactus web.xml configuration -->
> <copy todir="${admin.build.dir}/WEB-INF"
> file="web/admin/WEB-INF/web.xml"
> overwrite="yes">
> <filterset>
> <filter token="start.cactus.config" value="-->" />
> <filter token="end.cactus.config" value="<!--" />
> </filterset>
> </copy>
>
> In web.xml I have this:
>
> <!-- Cactus configuration
> Note: Do not place any XML comments in this Cactus configuration section
> (Ant's
> filtered copy is used to activate this configuration when the test web
> application is built)
> -->
> <!-- Begin Cactus Configuration @start.cactus.config@
> <servlet>
> <servlet-name>ServletRedirector</servlet-name>
>
>
<servlet-class>org.apache.cactus.server.ServletTestRedirector</servlet-class
> >
> </servlet>
>
> <servlet>
> <servlet-name>JspRedirector</servlet-name>
> <jsp-file>/somewhere/jspRedirector.jsp</jsp-file>
> </servlet>
>
> <servlet-mapping>
> <servlet-name>ServletRedirector</servlet-name>
> <url-pattern>/ServletRedirector/</url-pattern>
> </servlet-mapping>
>
> <servlet-mapping>
> <servlet-name>JspRedirector</servlet-name>
> <url-pattern>/JspRedirector/</url-pattern>
> </servlet-mapping>
>
> @end.cactus.config@ End Cactus Configuration -->
>
>
>
>
> ----- Original Message -----
> From: "Gennis Emerson" <ge...@vizdom.com>
> To: "Cactus Users List" <ca...@jakarta.apache.org>
> Sent: Friday, November 02, 2001 10:46 PM
> Subject: Re: conditional building of Cactus deployments
>
>
> > Erik Hatcher wrote:
> > >
> > > ----- Original Message -----
> > > From: "Vincent Massol" <vm...@octo.com>
> > > > yep, except I don't how it would work. The filter work this way: you
> > > define
> > > > a token in your web.xml (such as @cactus.web.xml@) and then in
> build.xml,
> > > > you would define the filter : <filter token="cactus.web.xml"
> > > value="xxx"/>.
> > > >
> > > > The problem is xxx ? Are you going to write the full cactus web.xml
> part
> > > in
> > > > a string ... ?
> > >
> > > Yes.
> > >
> > > <filter filtersfile="..."/>
> > >
> > > The filters file would have the full Cactus web.xml part. Wouldn't be
> > > pretty, but it would never need to be touched once specified. It'd
get
> too
> > > ugly with <, >, and " stuff in a <filter> 'value'.
> >
> >
> > I've been doing essentially that for a while and been satisfied with it.
> >
> > In my web.xml:
> >
> > <servlet> tags
> >
> > @cactus.redirectorservlet@
> >
> > <servlet-mapping> tags
> >
> > In build.xml, for regular builds:
> >
> > <filter token="cactus.redirectorservlet" value=""/>
> > <copy todir="${webapp.dir}/WEB-INF"
> > file="${basedir}/etc/web.xml"
> > filtering="yes"/>
> >
> > and for test builds:
> >
> > <filter filtersfile="${basedir}/etc/test/cactus.properties"/>
> > <copy file="${basedir}/etc/web.xml"
> > todir="${webapp.dir}/WEB-INF"
> > overwrite="yes"
> > filtering="yes"/>
> >
> > I put the config in cactus.properties because it seemed like an easy
> > place to find it. This isn't going to wrap very well:
> >
> > cactus.redirectorservlet = \
> > <servlet> \
> > <servlet-name>ServletRedirector</servlet-name> \
> >
> >
>
<servlet-class>org.apache.cactus.server.ServletTestRedirector</servlet-class
> >
> > \
> > </servlet> \
> > <servlet-mapping> \
> > <servlet-name>ServletRedirector</servlet-name> \
> > <url-pattern>/ServletRedirector/</url-pattern> \
> > </servlet-mapping>
> >
> >
> > Basically, the run-tests target does a regular compilation, then
> > compiles the test classes into the same web app, copies in test support
> > files (junit, cactus, the filtered web.xml), and runs the tests. We
> > don't deploy with war files, so I don't have any experience with that.
> >
> > Gennis
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: conditional building of Cactus deployments
Posted by Erik Hatcher <li...@ehatchersolutions.com>.
Just for everyone's benefit, here's how I accomplished conditional inclusion
of Cactus web.xml configuration. My web.xml file is capable of working
standalone without requiring any filtered copy to work. In Ant I'm doing
this:
<!-- Activate the Cactus web.xml configuration -->
<copy todir="${admin.build.dir}/WEB-INF"
file="web/admin/WEB-INF/web.xml"
overwrite="yes">
<filterset>
<filter token="start.cactus.config" value="-->" />
<filter token="end.cactus.config" value="<!--" />
</filterset>
</copy>
In web.xml I have this:
<!-- Cactus configuration
Note: Do not place any XML comments in this Cactus configuration section
(Ant's
filtered copy is used to activate this configuration when the test web
application is built)
-->
<!-- Begin Cactus Configuration @start.cactus.config@
<servlet>
<servlet-name>ServletRedirector</servlet-name>
<servlet-class>org.apache.cactus.server.ServletTestRedirector</servlet-class
>
</servlet>
<servlet>
<servlet-name>JspRedirector</servlet-name>
<jsp-file>/somewhere/jspRedirector.jsp</jsp-file>
</servlet>
<servlet-mapping>
<servlet-name>ServletRedirector</servlet-name>
<url-pattern>/ServletRedirector/</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>JspRedirector</servlet-name>
<url-pattern>/JspRedirector/</url-pattern>
</servlet-mapping>
@end.cactus.config@ End Cactus Configuration -->
----- Original Message -----
From: "Gennis Emerson" <ge...@vizdom.com>
To: "Cactus Users List" <ca...@jakarta.apache.org>
Sent: Friday, November 02, 2001 10:46 PM
Subject: Re: conditional building of Cactus deployments
> Erik Hatcher wrote:
> >
> > ----- Original Message -----
> > From: "Vincent Massol" <vm...@octo.com>
> > > yep, except I don't how it would work. The filter work this way: you
> > define
> > > a token in your web.xml (such as @cactus.web.xml@) and then in
build.xml,
> > > you would define the filter : <filter token="cactus.web.xml"
> > value="xxx"/>.
> > >
> > > The problem is xxx ? Are you going to write the full cactus web.xml
part
> > in
> > > a string ... ?
> >
> > Yes.
> >
> > <filter filtersfile="..."/>
> >
> > The filters file would have the full Cactus web.xml part. Wouldn't be
> > pretty, but it would never need to be touched once specified. It'd get
too
> > ugly with <, >, and " stuff in a <filter> 'value'.
>
>
> I've been doing essentially that for a while and been satisfied with it.
>
> In my web.xml:
>
> <servlet> tags
>
> @cactus.redirectorservlet@
>
> <servlet-mapping> tags
>
> In build.xml, for regular builds:
>
> <filter token="cactus.redirectorservlet" value=""/>
> <copy todir="${webapp.dir}/WEB-INF"
> file="${basedir}/etc/web.xml"
> filtering="yes"/>
>
> and for test builds:
>
> <filter filtersfile="${basedir}/etc/test/cactus.properties"/>
> <copy file="${basedir}/etc/web.xml"
> todir="${webapp.dir}/WEB-INF"
> overwrite="yes"
> filtering="yes"/>
>
> I put the config in cactus.properties because it seemed like an easy
> place to find it. This isn't going to wrap very well:
>
> cactus.redirectorservlet = \
> <servlet> \
> <servlet-name>ServletRedirector</servlet-name> \
>
>
<servlet-class>org.apache.cactus.server.ServletTestRedirector</servlet-class
>
> \
> </servlet> \
> <servlet-mapping> \
> <servlet-name>ServletRedirector</servlet-name> \
> <url-pattern>/ServletRedirector/</url-pattern> \
> </servlet-mapping>
>
>
> Basically, the run-tests target does a regular compilation, then
> compiles the test classes into the same web app, copies in test support
> files (junit, cactus, the filtered web.xml), and runs the tests. We
> don't deploy with war files, so I don't have any experience with that.
>
> Gennis
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: conditional building of Cactus deployments
Posted by Erik Hatcher <li...@ehatchersolutions.com>.
Gennis,
Thanks for posting this.... you just saved me 10 - 15 minutes of work and
I'm sure we can all use any extra time we can squeeze into our projects.
Erik
----- Original Message -----
From: "Gennis Emerson" <ge...@vizdom.com>
To: "Cactus Users List" <ca...@jakarta.apache.org>
Sent: Friday, November 02, 2001 10:46 PM
Subject: Re: conditional building of Cactus deployments
> Erik Hatcher wrote:
> >
> > ----- Original Message -----
> > From: "Vincent Massol" <vm...@octo.com>
> > > yep, except I don't how it would work. The filter work this way: you
> > define
> > > a token in your web.xml (such as @cactus.web.xml@) and then in
build.xml,
> > > you would define the filter : <filter token="cactus.web.xml"
> > value="xxx"/>.
> > >
> > > The problem is xxx ? Are you going to write the full cactus web.xml
part
> > in
> > > a string ... ?
> >
> > Yes.
> >
> > <filter filtersfile="..."/>
> >
> > The filters file would have the full Cactus web.xml part. Wouldn't be
> > pretty, but it would never need to be touched once specified. It'd get
too
> > ugly with <, >, and " stuff in a <filter> 'value'.
>
>
> I've been doing essentially that for a while and been satisfied with it.
>
> In my web.xml:
>
> <servlet> tags
>
> @cactus.redirectorservlet@
>
> <servlet-mapping> tags
>
> In build.xml, for regular builds:
>
> <filter token="cactus.redirectorservlet" value=""/>
> <copy todir="${webapp.dir}/WEB-INF"
> file="${basedir}/etc/web.xml"
> filtering="yes"/>
>
> and for test builds:
>
> <filter filtersfile="${basedir}/etc/test/cactus.properties"/>
> <copy file="${basedir}/etc/web.xml"
> todir="${webapp.dir}/WEB-INF"
> overwrite="yes"
> filtering="yes"/>
>
> I put the config in cactus.properties because it seemed like an easy
> place to find it. This isn't going to wrap very well:
>
> cactus.redirectorservlet = \
> <servlet> \
> <servlet-name>ServletRedirector</servlet-name> \
>
>
<servlet-class>org.apache.cactus.server.ServletTestRedirector</servlet-class
>
> \
> </servlet> \
> <servlet-mapping> \
> <servlet-name>ServletRedirector</servlet-name> \
> <url-pattern>/ServletRedirector/</url-pattern> \
> </servlet-mapping>
>
>
> Basically, the run-tests target does a regular compilation, then
> compiles the test classes into the same web app, copies in test support
> files (junit, cactus, the filtered web.xml), and runs the tests. We
> don't deploy with war files, so I don't have any experience with that.
>
> Gennis
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: conditional building of Cactus deployments
Posted by Gennis Emerson <ge...@vizdom.com>.
Erik Hatcher wrote:
>
> ----- Original Message -----
> From: "Vincent Massol" <vm...@octo.com>
> > yep, except I don't how it would work. The filter work this way: you
> define
> > a token in your web.xml (such as @cactus.web.xml@) and then in build.xml,
> > you would define the filter : <filter token="cactus.web.xml"
> value="xxx"/>.
> >
> > The problem is xxx ? Are you going to write the full cactus web.xml part
> in
> > a string ... ?
>
> Yes.
>
> <filter filtersfile="..."/>
>
> The filters file would have the full Cactus web.xml part. Wouldn't be
> pretty, but it would never need to be touched once specified. It'd get too
> ugly with <, >, and " stuff in a <filter> 'value'.
I've been doing essentially that for a while and been satisfied with it.
In my web.xml:
<servlet> tags
@cactus.redirectorservlet@
<servlet-mapping> tags
In build.xml, for regular builds:
<filter token="cactus.redirectorservlet" value=""/>
<copy todir="${webapp.dir}/WEB-INF"
file="${basedir}/etc/web.xml"
filtering="yes"/>
and for test builds:
<filter filtersfile="${basedir}/etc/test/cactus.properties"/>
<copy file="${basedir}/etc/web.xml"
todir="${webapp.dir}/WEB-INF"
overwrite="yes"
filtering="yes"/>
I put the config in cactus.properties because it seemed like an easy
place to find it. This isn't going to wrap very well:
cactus.redirectorservlet = \
<servlet> \
<servlet-name>ServletRedirector</servlet-name> \
<servlet-class>org.apache.cactus.server.ServletTestRedirector</servlet-class>
\
</servlet> \
<servlet-mapping> \
<servlet-name>ServletRedirector</servlet-name> \
<url-pattern>/ServletRedirector/</url-pattern> \
</servlet-mapping>
Basically, the run-tests target does a regular compilation, then
compiles the test classes into the same web app, copies in test support
files (junit, cactus, the filtered web.xml), and runs the tests. We
don't deploy with war files, so I don't have any experience with that.
Gennis
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: conditional building of Cactus deployments
Posted by Erik Hatcher <li...@ehatchersolutions.com>.
----- Original Message -----
From: "Vincent Massol" <vm...@octo.com>
> yep, except I don't how it would work. The filter work this way: you
define
> a token in your web.xml (such as @cactus.web.xml@) and then in build.xml,
> you would define the filter : <filter token="cactus.web.xml"
value="xxx"/>.
>
> The problem is xxx ? Are you going to write the full cactus web.xml part
in
> a string ... ?
Yes.
<filter filtersfile="..."/>
The filters file would have the full Cactus web.xml part. Wouldn't be
pretty, but it would never need to be touched once specified. It'd get too
ugly with <, >, and " stuff in a <filter> 'value'.
> > ... and I'd get the pleasure of working with Nick again!
> >
>
> you two know each other ... :) ?
You could say that! :)
We were co-workers up until a month ago. He was our Cactus expert, now I'm
out all on my own struggling wishing he was here pairing with me XP-style.
Erik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: conditional building of Cactus deployments
Posted by Vincent Massol <vm...@octo.com>.
----- Original Message -----
From: "Erik Hatcher" <li...@ehatchersolutions.com>
To: "Cactus Users List" <ca...@jakarta.apache.org>
Sent: Friday, November 02, 2001 6:23 PM
Subject: Re: conditional building of Cactus deployments
>
> ----- Original Message -----
> From: "Vincent Massol" <vm...@octo.com>
>
> > Solution 1 :
> > * Have 2 ant targets : test-junit and test-cactus and just call the one
> you
> > want
>
> Yup, I'm already doing this. I was mainly looking to see what others were
> doing so that I don't reinvent the wheel. But I'm perfectly happy coding
it
> all myself - me and Ant are good buddies! :)
>
> > Solution:
> > * Write an XSL stylesheet that contains the cactus redirectors. Tell me
if
> > you need help (it is very easy if you know XSL)
> > * Use the style ant task to transform your web.xml (production one) into
a
> > web.xml (test one). The condition to perform the style task or not could
> be
> > based either on the target name as in solution 1 above or on the
> definition
> > or not of cactus.include (solution 2 above).
>
> Those are reasonable suggestions, although perhaps a bit overkill for just
> having something commented out or not included in web.xml. I think the
> filtered copy idea is the best so far.
>
yep, except I don't how it would work. The filter work this way: you define
a token in your web.xml (such as @cactus.web.xml@) and then in build.xml,
you would define the filter : <filter token="cactus.web.xml" value="xxx"/>.
The problem is xxx ? Are you going to write the full cactus web.xml part in
a string ... ?
> > > * I do not want duplication in my build.xml
> >
> > euh.. not sure what you mean. all solutions presented here have no
> > duplications
>
> What I was getting at was that I didn't want two different web.xml files,
> and didn't want two <war> tasks (one for production and one for Cactus
> inclusion). I was just speaking out-loud on that one, I suppose.
>
> > > I'm going to start tackling these issues myself, but if its already
been
> > > implemented nicely then it'd save me some time and I'd be able to
> > contribute
> > > my efforts on the Cactus project in other areas! :)
> >
> > please do ... :)
>
> ... and I'd get the pleasure of working with Nick again!
>
you two know each other ... :) ?
> Erik
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: conditional building of Cactus deployments
Posted by Vincent Massol <vm...@octo.com>.
----- Original Message -----
From: "Erik Hatcher" <li...@ehatchersolutions.com>
To: "Cactus Users List" <ca...@jakarta.apache.org>
Sent: Friday, November 02, 2001 6:23 PM
Subject: Re: conditional building of Cactus deployments
>
> ----- Original Message -----
> From: "Vincent Massol" <vm...@octo.com>
>
> > Solution 1 :
> > * Have 2 ant targets : test-junit and test-cactus and just call the one
> you
> > want
>
> Yup, I'm already doing this. I was mainly looking to see what others were
> doing so that I don't reinvent the wheel. But I'm perfectly happy coding
it
> all myself - me and Ant are good buddies! :)
>
> > Solution:
> > * Write an XSL stylesheet that contains the cactus redirectors. Tell me
if
> > you need help (it is very easy if you know XSL)
> > * Use the style ant task to transform your web.xml (production one) into
a
> > web.xml (test one). The condition to perform the style task or not could
> be
> > based either on the target name as in solution 1 above or on the
> definition
> > or not of cactus.include (solution 2 above).
>
> Those are reasonable suggestions, although perhaps a bit overkill for just
> having something commented out or not included in web.xml. I think the
> filtered copy idea is the best so far.
It's more complex than you imagine ... :)
For example: For each servet definition there is an associated mapping.
However, as you may know, the order of elements in web.xml is important
(servlet definition must come before mappings). So if you have your own
application servlet in one web.xml file and the cactus one in another file,
you need to mix the 2 taking into account the order.
The only way that I know of to do this in a simple way is XSL, which is
exactly meant for this ... If I find some time, I'll write the XSL
stylesheet to do this (quite easy to write).
-Vincent
>
> > > * I do not want duplication in my build.xml
> >
> > euh.. not sure what you mean. all solutions presented here have no
> > duplications
>
> What I was getting at was that I didn't want two different web.xml files,
> and didn't want two <war> tasks (one for production and one for Cactus
> inclusion). I was just speaking out-loud on that one, I suppose.
>
> > > I'm going to start tackling these issues myself, but if its already
been
> > > implemented nicely then it'd save me some time and I'd be able to
> > contribute
> > > my efforts on the Cactus project in other areas! :)
> >
> > please do ... :)
>
> ... and I'd get the pleasure of working with Nick again!
>
> Erik
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: conditional building of Cactus deployments
Posted by Erik Hatcher <li...@ehatchersolutions.com>.
----- Original Message -----
From: "Vincent Massol" <vm...@octo.com>
> Solution 1 :
> * Have 2 ant targets : test-junit and test-cactus and just call the one
you
> want
Yup, I'm already doing this. I was mainly looking to see what others were
doing so that I don't reinvent the wheel. But I'm perfectly happy coding it
all myself - me and Ant are good buddies! :)
> Solution:
> * Write an XSL stylesheet that contains the cactus redirectors. Tell me if
> you need help (it is very easy if you know XSL)
> * Use the style ant task to transform your web.xml (production one) into a
> web.xml (test one). The condition to perform the style task or not could
be
> based either on the target name as in solution 1 above or on the
definition
> or not of cactus.include (solution 2 above).
Those are reasonable suggestions, although perhaps a bit overkill for just
having something commented out or not included in web.xml. I think the
filtered copy idea is the best so far.
> > * I do not want duplication in my build.xml
>
> euh.. not sure what you mean. all solutions presented here have no
> duplications
What I was getting at was that I didn't want two different web.xml files,
and didn't want two <war> tasks (one for production and one for Cactus
inclusion). I was just speaking out-loud on that one, I suppose.
> > I'm going to start tackling these issues myself, but if its already been
> > implemented nicely then it'd save me some time and I'd be able to
> contribute
> > my efforts on the Cactus project in other areas! :)
>
> please do ... :)
... and I'd get the pleasure of working with Nick again!
Erik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: conditional building of Cactus deployments
Posted by Vincent Massol <vm...@octo.com>.
----- Original Message -----
From: "Erik Hatcher" <li...@ehatchersolutions.com>
To: <ca...@jakarta.apache.org>
Sent: Friday, November 02, 2001 10:14 AM
Subject: conditional building of Cactus deployments
> Where can I find good examples of how folks are architecting their Ant
> builds such that a release version is built without any test code in it
> whatsoever and when the tests are run the deployment is built to include
the
> necessary pieces for Cactus testing?
>
> Here are the issues I'm facing:
>
> * Some tests are non-Cactus JUnit tests. Some are Cactus. I'm separating
> them by directory structure. There needs to be a distinction in the Ant
> targets on which tests get run and such.
>
Solution 1 :
* Have 2 ant targets : test-junit and test-cactus and just call the one you
want
Solution 2:
* Have a build.properties file where you define properties that depend on
your environment (this file is not checked in CVS - although there is a
commented build.properties.sample one). See the one in the cactus build
directory.
* Define a property : cactus.include = true
* Have a test target that depends on test-junit and test-cactus
* Use an if="cactus.include" in the definition of the test-cactus target
> * web.xml allow conditional inclusion of the redirector configuration
>
Solution:
* Write an XSL stylesheet that contains the cactus redirectors. Tell me if
you need help (it is very easy if you know XSL)
* Use the style ant task to transform your web.xml (production one) into a
web.xml (test one). The condition to perform the style task or not could be
based either on the target name as in solution 1 above or on the definition
or not of cactus.include (solution 2 above).
> * I do not want duplication in my build.xml
euh.. not sure what you mean. all solutions presented here have no
duplications
>
> I'm going to start tackling these issues myself, but if its already been
> implemented nicely then it'd save me some time and I'd be able to
contribute
> my efforts on the Cactus project in other areas! :)
please do ... :)
thanks
-Vincent
>
> Erik
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: conditional building of Cactus deployments
Posted by Nicholas Lesiecki <ni...@eblox.com>.
Hi Erik! I wish I could offer more help but we've been struggling with basic
Ant issues. Offhand I'd say use the filter-copy to modify the web.xml as you
suggest. Maybe a token value like:
@redirector.mapping@
test.properties would contain:
redirector.mapping=<...full mapping here...>
prodcution.properties could contain:
redirector.mapping=<!---->
As to excluding the test classes, I think we keep them in a separate
directory an explicitly include or exclude that directory from compilation.
Cheers,
Nick
-----Original Message-----
From: Erik Hatcher [mailto:lists@ehatchersolutions.com]
Sent: Friday, November 02, 2001 8:01 AM
To: Cactus Users List
Subject: Re: conditional building of Cactus deployments
----- Original Message -----
From: "Jim Cheesman" <jc...@msl.es>
> >* Some tests are non-Cactus JUnit tests. Some are Cactus. I'm
separating
> >them by directory structure. There needs to be a distinction in the Ant
> >targets on which tests get run and such.
>
>
> How/why do you want to distinguish between them?
Because regular JUnit tests don't require an app. server installed. I want
the flexibility to build and run just the plain ol' JUnit tests or step up
to the Cactus ones separately. This piece is no big deal Ant-wise.
> >* web.xml allow conditional inclusion of the redirector configuration
>
> Think about setting up (i.e. building then copying a war) a test
> application. Then delete it.
I don't quite understand what you mean. I want a production-quality web.xml
that does not have the Cactus redirectors in there, and the capability to
turn them on when building the test deployment. I'll figure out a way to
handle this also either using filtered copy in Ant or some other way - I was
just wondering what others were doing in this regard.
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: conditional building of Cactus deployments
Posted by Jim Cheesman <jc...@msl.es>.
At 04:00 PM 02/11/01, you wrote:
>----- Original Message -----
>From: "Jim Cheesman" <jc...@msl.es>
> > >* Some tests are non-Cactus JUnit tests. Some are Cactus. I'm
>separating
> > >them by directory structure. There needs to be a distinction in the Ant
> > >targets on which tests get run and such.
> >
> >
> > How/why do you want to distinguish between them?
>
>Because regular JUnit tests don't require an app. server installed. I want
>the flexibility to build and run just the plain ol' JUnit tests or step up
>to the Cactus ones separately. This piece is no big deal Ant-wise.
Fair enough ;) Try using "if" in the ant task, and passing in a value from
the command line:
<target name="full">
<antcall target="normalTests" />
<antcall target="cactusTests" />
</target>
<target name="cactusTests" if="withCactus">
...
> > >* web.xml allow conditional inclusion of the redirector configuration
> >
> > Think about setting up (i.e. building then copying a war) a test
> > application. Then delete it.
>
>I don't quite understand what you mean. I want a production-quality web.xml
>that does not have the Cactus redirectors in there, and the capability to
>turn them on when building the test deployment.
I don't know if that's really possible - I think you'll have to build two
webapps - one for testing and the other as production. We're far enough
away from deadline here that adding the redirectors to web.xml is no great
deal.
--
* Jim Cheesman *
Trabajo:
jchees@msl.es - (34)(91) 724 9200 x 2360
In retrospect it becomes clear
that hindsight is definitely overrated
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: conditional building of Cactus deployments
Posted by Erik Hatcher <li...@ehatchersolutions.com>.
----- Original Message -----
From: "Jim Cheesman" <jc...@msl.es>
> >* Some tests are non-Cactus JUnit tests. Some are Cactus. I'm
separating
> >them by directory structure. There needs to be a distinction in the Ant
> >targets on which tests get run and such.
>
>
> How/why do you want to distinguish between them?
Because regular JUnit tests don't require an app. server installed. I want
the flexibility to build and run just the plain ol' JUnit tests or step up
to the Cactus ones separately. This piece is no big deal Ant-wise.
> >* web.xml allow conditional inclusion of the redirector configuration
>
> Think about setting up (i.e. building then copying a war) a test
> application. Then delete it.
I don't quite understand what you mean. I want a production-quality web.xml
that does not have the Cactus redirectors in there, and the capability to
turn them on when building the test deployment. I'll figure out a way to
handle this also either using filtered copy in Ant or some other way - I was
just wondering what others were doing in this regard.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: conditional building of Cactus deployments
Posted by Jim Cheesman <jc...@msl.es>.
At 11:14 AM 02/11/01, you wrote:
>Where can I find good examples of how folks are architecting their Ant
>builds such that a release version is built without any test code in it
>whatsoever and when the tests are run the deployment is built to include the
>necessary pieces for Cactus testing?
Nothing special here - I build and jar everything, test, then delete the
test classes and source, rebuild.
(Note that I'm obviously copying the source from somewhere else!)
>Here are the issues I'm facing:
>
>* Some tests are non-Cactus JUnit tests. Some are Cactus. I'm separating
>them by directory structure. There needs to be a distinction in the Ant
>targets on which tests get run and such.
How/why do you want to distinguish between them?
>* web.xml allow conditional inclusion of the redirector configuration
Think about setting up (i.e. building then copying a war) a test
application. Then delete it.
>* I do not want duplication in my build.xml
Call the war building task twice, before testing, then after
testing/deletion of test classes.
>I'm going to start tackling these issues myself, but if its already been
>implemented nicely then it'd save me some time and I'd be able to contribute
>my efforts on the Cactus project in other areas! :)
>
> Erik
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
* Jim Cheesman *
Trabajo:
jchees@msl.es - (34)(91) 724 9200 x 2360
In retrospect it becomes clear
that hindsight is definitely overrated
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>