As Ted often reminds us, the only votes that *actually* count are those from
people who *actually* _do_ the work. So, I'm not sure why this is even up
for a vote.
My vote is always for Maven. Maven is just smart software. There's no
arguing that. The only *valid* argument I've ever heard (on any of the
mailing lists I've been on) wrt choosing Ant over Maven is that people don't
want to learn a new build tool.
While some would call that a "lame" excuse, I think that can be a real
concern, especially if time is important. No one wants to explain to the
Director of IT that the reason the iteration is delayed is because someone
is trying to learn a new build tool.
That said, the closest parallel I can draw on here is how some describe the
choice to use Spring. There are actually people out there who call
themselves architects who say things like "should we use EJB or Spring" or
even worse (I'm not lying here) "should we use Spring or Hibernate".
It doesn't matter what you are using for persistence (iBatis, Hibernate,
EJB, POJO/DAO), Spring just makes it all easier. Sure you have to learn
something new (how to configure Spring), but what you get for free (right
out of the box) is justification alone.....sound familiar???
I have always been happy to help anyone with any Maven question they have,
(I think Wendy would agree with that ;) but they have to decide they want to
use Maven. Being forced to use Maven is not the way to learn it (or
anything else for that matter).
While I've been pretty slammed with work lately, I'll gladly help anyone
with Maven questions.
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
MSN: [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)
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]> 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 naming things precisely is going to be important.
Historically (since Struts 1.1) a version of Tiles (in package
org.apache.struts.tiles) that is integrated with, and dependent on,
Struts has been included. There is a current effort in the Struts
Sandbox to create a *Standalone* version of TIles (in package
org.apache.tiles) that has no such dependencies, and would be more
easily used in other projects like MyFaces and Shale. If you guys
would like to help make that happen (either in the Struts sandbox, or
possibly (thinking out loud) in a separate Jakarta subproject), it
would be great.
The current sandbox code has nightly builds available:
http://cvs.apache.org/builds/struts/nightly/sandbox/tiles-core/
and works with Shale already. The code was a direct port from the
current Struts 1.3.x trunk (well, as of a week or so ago, but there
haven't been any Tiles changes), adding a standalone TilesServlet for
initialization and removing the Struts dependencies.
Beyond just the port, I would also like us to consider remodelling the
standadlone Tiles APIs to work better in a portlet environment (right
now, there's a lot of passing HttpServletRequest and
HttpServletResponse objects around). We could take advantage of the
opportunity to break backwards compatibiltiy on the internal APIs and
fix this too.
-Matthias
Craig
david
Greg
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
