struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Mitchell" <jmitch...@apache.org>
Subject Re: ANT or Maven for Standalone Tiles (was Re: [Tiles] Struts Plugin in standalone Tiles)
Date Mon, 08 Aug 2005 18:48:51 GMT
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:   jmitchell@apache.org
Skype: jmitchtx

----- Original Message ----- 
From: "David Geary" <sabreware@earthlink.net>
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 <mwessendorf@pironet-ndh.com> 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: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message