Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of flamefew@gmail.com designates
 64.233.162.198 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=i8EKFFSB+9dRdRZy2Nyw1DqQc3c5zC+ruXeY5FhcjsoHRsonc70OY4SShRpnQyCiwNcw6URbr5NQG4RX/OBqryo7WURUfhQtWhxQlm3ihfhxz7ZdcrdGnRI6DuckIC0AImSTh8HO8EEi/BWiy30pZhJa7rhY72iwfD/vM8xCHVQ=
Message-ID: <31cc37360512181004l5f195daj6bb34362b6c6c464@mail.gmail.com>
Date: Sun, 18 Dec 2005 13:04:37 -0500
From: Henri Yandell <flamefew@gmail.com>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [all] Maven, help or hinderance?
In-Reply-To: <1134899534.5283.25.camel@knossos.elmet>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <43828F71.1020107@javactivity.org>
	 <439243AA.3030302@btopenworld.com>
	 <8a81b4af0512032009o7d8da42bs478f61e4c00eab6f@mail.gmail.com>
	 <43928E03.6030106@apache.org>
	 <1134312164.5187.173.camel@knossos.elmet>
	 <439C640B.7090209@apache.org>
	 <8a81b4af0512111016p74bd5730v2d598b07327897ce@mail.gmail.com>
	 <b22dff980512111433u707fae7bl7c5689b5a901d445@mail.gmail.com>
	 <31cc37360512162216t2ceacdb9ye2c64572eabe494b@mail.gmail.com>
	 <1134899534.5283.25.camel@knossos.elmet>

On 12/18/05, robert burrell donkin <robertburrelldonkin@blueyonder.co.uk> w=
rote:
> i think that there are two different kinds of specific need here. IMO
> both are not negotiable (for different reasons).
>
> the ASF has a few specific needs which maven either does not provide at
> the moment (for example, NOTICE.xml) or which maven should not provide
> since they are too specific to the ASF (for example, the symlink build
> structure). these needs are non-negotiable.
>
> i think that these needs are best satisfied by the creation of a jakarta
> or apache plug-in as suggested by brett.

Somewhat. Things like being on a weird set of plugin versions just
needs to be rolled back to the known version, unless it's transparent
to the user due to the commons-plugin dependencies.

> there are another set of needs which fall under best practise. over the
> last year (or two), the commons has started to come under intense
> scrutiny. we are now the establishment and any times that we fall short
> of the highest standards, we can expect to be held up as examples of bad
> practise throughout the java community. i agree with stephen that our
> releases now need to be of the highest possible standard. i'm no longer
> to willing to accept lower quality releases as a result of using maven.
> so again, these are not negotiable.

Depends. Highest possible standard makes it harder for development
momentum to happen. That's a given. If the level of quality is
damaging to the momentum of the community, then I'm +1 for releasing a
lower quality, keeping developer momentum is more important than code
quality.

The plugin should solve this, along with scripts etc. Basically we
need to keep a focus on developer simplicity. The lower the barrier to
entry/momentum, the easier it'll be for us to develop.

> in the past, we haven't been very effective (as we might) at feeding
> through these emerging best practises to maven. it's pretty much been

+1. We need to start yelling at maven to fix/add them and dealing with
the lower quality in the meantime instead of hacking them ourselves.
Increasingly this'll mean being on maven2, so we should be trying to
get there soon.

> only phil. i'm going to try to be more active (and hope others will do
> the same). however, it is clear that one problem we have is that the
> feedback cycle is too inefficient: we can't afford to wait a month or
> two for new plugin releases and we're finding it hard to ensure everyone
> has the required versions. perhaps managing our plugin would made this
> easier.

Perhaps, though I think we can afford to wait a month or two. Years
maybe not, but it's not the end of the world if we knowlingly
distribute a few more jars without the Vendor-Distribution-Id for
example (or whatever that property name was).

Hen

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