Return-Path: 
 <dev-return-93402-apmail-maven-dev-archive=maven.apache.org@maven.apache.org>
Delivered-To: apmail-maven-dev-archive@www.apache.org
Received: (qmail 47674 invoked from network); 26 Apr 2010 12:40:56 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 26 Apr 2010 12:40:56 -0000
Received: (qmail 24955 invoked by uid 500); 26 Apr 2010 12:40:55 -0000
Delivered-To: apmail-maven-dev-archive@maven.apache.org
Received: (qmail 24676 invoked by uid 500); 26 Apr 2010 12:40:55 -0000
Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@maven.apache.org>
List-Help: <mailto:dev-help@maven.apache.org>
List-Post: <mailto:dev@maven.apache.org>
List-Id: "Maven Developers List" <dev.maven.apache.org>
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Delivered-To: mailing list dev@maven.apache.org
Received: (qmail 24668 invoked by uid 99); 26 Apr 2010 12:40:55 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Apr 2010 12:40:55 +0000
X-ASF-Spam-Status: No, hits=0.3 required=10.0
	tests=AWL,HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of jason@sonatype.com designates
 63.246.20.110 as permitted sender)
Received: from [63.246.20.110] (HELO sonatype01.sonatype.com) (63.246.20.110)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Apr 2010 12:40:49 +0000
Received: (qmail 3930 invoked by uid 89); 26 Apr 2010 12:40:28 -0000
Received: from unknown (HELO ?10.0.1.201?) (jason@maven.org@99.225.12.75)
  by 63-246-20-110.contegix.com with ESMTPA; 26 Apr 2010 12:40:28 -0000
From: Jason van Zyl <jason@sonatype.com>
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: multipart/alternative; boundary=Apple-Mail-35--226832119
Subject: Re: Concurrency in m3 - a status report
Date: Mon, 26 Apr 2010 08:40:27 -0400
In-Reply-To: <4BD5735F.7030902@udo.edu>
To: "Maven Developers List" <dev@maven.apache.org>
References: <t2m262c6c681004080220sd782a0f6j24cd3da744eede07@mail.gmail.com>
	 <1272233313.24698.99.camel@office>
	 <k2r4c39e3031004260113i47ac26faib25b9b4cf1be609c@mail.gmail.com>
	 <4BD555FD.6090300@gmail.com>
	 <t2m4c39e3031004260215r14b2d87fxbca9351dc3f13d91@mail.gmail.com>
 <n2r88c1b41004260235h14dbc3dao24c6dd47e2f854f1@mail.gmail.com>
 <4BD5735F.7030902@udo.edu>
Message-Id: <F6DBE679-90EF-400B-9C67-BC0C68D3AD3A@sonatype.com>
X-Mailer: Apple Mail (2.1078)

--Apple-Mail-35--226832119
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Apr 26, 2010, at 7:05 AM, Benjamin Bentmann wrote:

> Stephen Connolly wrote:
>=20
>> ... but each release of m3
>> would have it's own compatibility info and we would have another =
state:
>> unknown
>>=20
>> e.g.
>>=20
>> <thread-safety>
>>   <plugin groupId=3D"..." artifactId=3D"...">
>>     <wieve-mode action=3D"ban" versions=3D"...">message</wieve-mode>
>>     <wieve-mode action=3D"warn" versions=3D"...">message</wieve-mode>
>>     <wieve-mode action=3D"checked" versions=3D"..."/>
>>     <parallel-mode action=3D"ban" =
versions=3D"...">message</paralle-mode>
>>     <parallel-mode action=3D"warn" =
versions=3D"...">message</paralle-mode>
>>     <parallel-mode action=3D"checked" =
versions=3D"...">message</paralle-mode>
>>   </plugin>
>> </thread-safety>
>>=20
>> Any plugins not in the list would be "unknown" and the user gets a =
big fat
>> warning
>=20
> Did you also consider the maintainability aspect of such a list? No =
user wants to see "big fat warnings" that are irrelevant for their =
builds so I envision users will either bug the plugin author or us =
directly to add plugin X to this list and ask us to roll a new release =
of this list such that they get rid of that warning.
>=20
> Plugins should be self-describing, that's why mojo annotations and the =
plugin descriptor exists. I definitively don't want to see us =
maintaining the metadata for 3rd party plugins.
>=20
> For this reason, I prefer the original suggestion to introduce a new =
mojo annotation. Apparently, whatever mojo annotation we come up with, =
it's not present in any existing plugin release. Now, for plugins =
missing the threading anno, what is the safer assumption with respect to =
proper build results: That mojo X is thread-safe (when this was never =
before a concern) or that it isn't?
>=20
> IMHO, there's only way to limit this "oh, I deliberately enabled nitro =
injection and now my engine blew up, how am I supposed to know that this =
is dangerous?": Unless a mojo is explicitly marked with @threadsafe, =
issue a warning like
>=20

Right. It's pretty simple. If the author has worked on and tested then =
they can mark the mojo as such. Otherwise the mojo gets no benefit from =
the parallel mode.

A @nothreadsafe annotation makes no sense. We're going to go around and =
mark everyone else's mojos? That's not going to work and neither is =
maintaining third party information. If we start the process of adding =
the annotation we can easily get the basic mojos in the default =
lifecycle annotated accordingly. If we deem this a requirement for the =
3.0 release then we'll work on plugins for a little while before =
releasing 3.0.=20

> "Goal X does not appear to support concurrent execution and might fail =
the build, use parallel building at your own risk."
>=20
>=20
> Benjamin
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>=20

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------


--Apple-Mail-35--226832119--