Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: pass (athena.apache.org: domain of manfred.geiler@gmail.com
 designates 209.85.146.182 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Ptv661+AqZG4PKOF/G8CPH/cX0DDZjD7BK71uWchwE3vDEhsiOUi3B33TaIdRruwWvjNTsOE1UotRmmiH8+Q1SV+d5Ri0M1PvxUFgQsnrFrKVX1gRYWok48oQB52YOVEqNJGV1qfFXPRt7QD5nPHpMOHad4N7+Nozp3KmZOa0K4=
Message-ID: <564d4f680710290212l521a06f7y9ed813ade711ff0d@mail.gmail.com>
Date: Mon, 29 Oct 2007 10:12:55 +0100
From: "Manfred Geiler" <manfred.geiler@gmail.com>
To: "MyFaces Development" <dev@myfaces.apache.org>
Subject: Re: [vote] start up the MyFaces Commons project
In-Reply-To: <4724DE13.3040200@ops.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <471F5903.5030107@ops.co.at>
	 <564d4f680710270510i2529db10x7d13f23428fe255a@mail.gmail.com>
	 <4724DE13.3040200@ops.co.at>

On 10/28/07, Mario Ivankovits <mario@ops.co.at> wrote:
> Hi!
> > 1. Clear separation of API and IMPL (at least on package level, better
> > by separate artifacts).  Mind that the idea behind these commons
> > classes is that many other projects use them - and therefore depend on
> > them. So a clear and stable API is essential.
> >
> I wanted this to be an easy utils project and not yet-another-framework.
> In fact, there might be stuff in there which has an API and an IMPL, but
> this is not necessarily required. Static utils classes wont have an API.
> Shouldn't it be possible to have a stable API even without separating it
> out?

Have a look at http://commons.apache.org/beanutils/apidocs/org/apache/commons/beanutils/BeanUtils.html
for an example how static utils CAN be clearly separated into api and impl.
The static method holders ("Utils" classes) are located in the api
subproject, the default implementation bean would live in the impl src
root.


> > 2. Let's start to name svn folders the same as the artifacts. This
> > seems to be best practice in many other maven projects. And there are
> > good reasons to do this.
> > So, the new project should be located in a folder named like
> > "myfaces-commons" with two sub folders "myfaces-commons-api" and
> > "myfaces-commons-impl".
> >
> I don't like that but wouldn't veto if we think this should be done that
> way, just, remember how this would look like:
>
> /home/im/projects/myfaces12/commons/myfaces-commons/myfaces-commons-api/src/main/java
> /home/im/projects/myfaces12/commons/myfaces-commons/myfaces-commons-impl/src/main/java
>
> I think the middle part is overly redundant.
>

There IS redundant information in the path. Yes. But the reason why
many developers prefer this naming scheme is human not technical.
Human brains are faster in recognizing icons and patterns than
thinking in hierachical structures. Imagine having many expanded
folders in your IDE or Explorer. It's simply faster to scan only the
leaves of your folder tree structure than to scan structurally: "Ok,
here is the folder 'api' - hmm which api? Ah, yes, it's attached to
something called 'commons'. Okaaaay. Hey, it's dangling on that
'myfaces' node. Yippieh, I found the 'myfaces-commons-api' folder!"
Ever wondered why most people like "labelling" their documents (or
emails or bookmarks!) more than file them in hierachical structures? I
admit, I once was a structure fanatic. My bookmarks all lived in deep
folder structures. And I seldom found them again. :-)
GMail, GMarks, Picasa changed my life...

;-)

--Manfred