Do you think the Maven developers can be convinced to make this the
default behavior for generated build.xml files? It isn't at the
moment. Case in point ... I generate nightly builds for a large
number of Jakarta Commons (and Commons Sandbox) projects. The
standard execution path for my
Message-
From: Craig McClanahan [mailto:[EMAIL PROTECTED]
Sent: Monday, August 08, 2005 5:53 PM
To: Struts Developers List
Subject: Re: [Tiles] Struts Plugin in standalone Tiles
On 8/8/05, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Yes, the intention is to keep standalone Tiles
On Aug 8, 2005, at 8:18 PM, Wendy Smoak wrote:
Both is also an option. :) There is already a Maven build for
Standalone Tiles-- it came over from struts-tiles when the files were
copied, and it works. The project.xml file needs a few changes-- I'll
check them in if no one minds.
In the
On 8/8/05, Phil Steitz [EMAIL PROTECTED] wrote:
Do you think the Maven developers can be convinced to make this the
default behavior for generated build.xml files? It isn't at the
moment. Case in point ... I generate nightly builds for a large
number of Jakarta Commons (and Commons
Both sounds good to me too. If nobody objects, that's what we'll do.
david
Le 05-08-08 à 19:59, Craig McClanahan a écrit :
On 8/8/05, Wendy Smoak [EMAIL PROTECTED] wrote:
From: David Geary [EMAIL PROTECTED]
I'm +1 for ANT. I agree with Joe's comment, but standalone Tiles
is not
part
Hi guys,
Is it possible to *use* Apache Tiles (standalone one) inside of Struts 1.2 ?
I didn't see a plugin inside of the tiles standalone dist.
thx,
Matthias
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Matthias Wessendorf wrote:
Hi guys,
Is it possible to *use* Apache Tiles (standalone one) inside of Struts 1.2 ?
I didn't see a plugin inside of the tiles standalone dist.
There is currently no plugin or TilesRequestProcessor in the Standalone
Tiles project. I question whether it would
On 05-08-08, at 08:23, Greg Reddin wrote:
Matthias Wessendorf wrote:
Hi guys,
Is it possible to *use* Apache Tiles (standalone one) inside of
Struts 1.2 ?
I didn't see a plugin inside of the tiles standalone dist.
There is currently no plugin or TilesRequestProcessor in the
Standalone
Yes, the intention is to keep standalone Tiles completely separate
from Struts. The plugin and request processor should be in Struts,
not standalone Tiles.
ok I see, but Tiles currently depends on Struts ... ;)
-Matthias
david
Greg
On 8/8/05, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Yes, the intention is to keep standalone Tiles completely separate
from Struts. The plugin and request processor should be in Struts,
not standalone Tiles.
ok I see, but Tiles currently depends on Struts ... ;)
Here's a spot where
While we're thinking about supporting portlets in standalone Tiles,
we need to
make another decision: do we use ANT or Maven to build it?
So, I'd like to call for a vote: ANT or Maven?
david
Le 05-08-08 à 09:53, Craig McClanahan a écrit :
On 8/8/05, Matthias Wessendorf [EMAIL PROTECTED]
Non-committer input:
If I had a vote I'd vote for Maven. I *prefer* Maven but I can work
with Ant.
It's not an issue that will keep me from supporting the project. I
prefer Maven because, to me, it makes dependency management, scripting
builds, and some other things easier (i.e. I have to
: [EMAIL PROTECTED]
Skype: jmitchtx
- Original Message -
From: David Geary [EMAIL PROTECTED]
To: Struts Developers List dev@struts.apache.org
Sent: Monday, August 08, 2005 1:26 PM
Subject: Vote: ANT or Maven for Standalone Tiles (was Re: [Tiles] Struts
Plugin in standalone Tiles
At 1:33 PM -0400 8/8/05, Ted Husted wrote:
+1 for Maven.
I don't have the bandwidth to support Ant for Struts 1.3.x, so unless
someone else steps up, we'll need to go with just Maven for Classic.
+1 for Maven; I think it will be confusing to use different build
strategies within Struts, and
On 8/8/05, David Geary [EMAIL PROTECTED] wrote:
While we're thinking about supporting portlets in standalone Tiles,
we need to
make another decision: do we use ANT or Maven to build it?
So, I'd like to call for a vote: ANT or Maven?
No surprise from my other comments, but +1 for Ant based
I'm +1 for ANT. I agree with Joe's comment, but standalone Tiles is
not part of Struts, so I don't think it will be confusing. Also Ted's
comments about Maven being most useful when it's used for a set of
projects convinced me even more to use ANT. It ain't called
standalone Tiles for
From: David Geary [EMAIL PROTECTED]
I'm +1 for ANT. I agree with Joe's comment, but standalone Tiles is not
part of Struts, so I don't think it will be confusing.
Both is also an option. :) There is already a Maven build for Standalone
Tiles-- it came over from struts-tiles when the files
On 8/8/05, Wendy Smoak [EMAIL PROTECTED] wrote:
From: David Geary [EMAIL PROTECTED]
I'm +1 for ANT. I agree with Joe's comment, but standalone Tiles is not
part of Struts, so I don't think it will be confusing.
Both is also an option. :) There is already a Maven build for Standalone
+1 for Maven. My reasons are in the other thread:
http://marc.theaimsgroup.com/?l=struts-devm=112354929615256w=2
--
Martin Cooper
On 8/8/05, David Geary [EMAIL PROTECTED] wrote:
While we're thinking about supporting portlets in standalone Tiles,
we need to
make another decision: do we use
From: Craig McClanahan [EMAIL PROTECTED]
I'd be ok with the both approach. It seems to work fine for Commons
packages. And the number of dependencies for standalone Tiles is
really small, so the redundant downloads don't bug me that much.
Redundant, how? Any one developer is likely to be
On 8/8/05, Wendy Smoak [EMAIL PROTECTED] wrote:
From: Craig McClanahan [EMAIL PROTECTED]
I'd be ok with the both approach. It seems to work fine for Commons
packages. And the number of dependencies for standalone Tiles is
really small, so the redundant downloads don't bug me that much.
The solution, from my understanding of Maven, is to decouple the build
environments so that they explicitly do *not* benefit from the shared
standardization advantage. At an absolute minimum, that seems to
imply separate dependency lists ... and that also seems to imply that
I'll end up with
On 8/8/05, James Mitchell [EMAIL PROTECTED] wrote:
The solution, from my understanding of Maven, is to decouple the build
environments so that they explicitly do *not* benefit from the shared
standardization advantage. At an absolute minimum, that seems to
imply separate dependency lists
From: Craig McClanahan [EMAIL PROTECTED]
So what should struts-faces do in detail, to avoid a dependency on
Struts Core 1.3.x?
The overall build file doesn't list any 1.3.0-dev dependencies, so they are
not inherited by Faces. The dependency was coming from struts-faces' own
project.xml
On 8/8/05, Wendy Smoak [EMAIL PROTECTED] wrote:
From: Craig McClanahan [EMAIL PROTECTED]
So what should struts-faces do in detail, to avoid a dependency on
Struts Core 1.3.x?
The overall build file doesn't list any 1.3.0-dev dependencies, so they are
not inherited by Faces. The
25 matches
Mail list logo
