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
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
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
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
18 matches
Mail list logo