Return-Path: 
 <dev-return-93404-apmail-maven-dev-archive=maven.apache.org@maven.apache.org>
Delivered-To: apmail-maven-dev-archive@www.apache.org
Received: (qmail 53133 invoked from network); 26 Apr 2010 12:49:59 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 26 Apr 2010 12:49:59 -0000
Received: (qmail 36102 invoked by uid 500); 26 Apr 2010 12:49:58 -0000
Delivered-To: apmail-maven-dev-archive@maven.apache.org
Received: (qmail 36053 invoked by uid 500); 26 Apr 2010 12:49:58 -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 36045 invoked by uid 99); 26 Apr 2010 12:49:58 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Apr 2010 12:49:58 +0000
X-ASF-Spam-Status: No, hits=2.2 required=10.0
	tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of stephen.alan.connolly@gmail.com
 designates 209.85.218.215 as permitted sender)
Received: from [209.85.218.215] (HELO mail-bw0-f215.google.com)
 (209.85.218.215)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Apr 2010 12:49:51 +0000
Received: by bwz7 with SMTP id 7so12148365bwz.36
        for <dev@maven.apache.org>; Mon, 26 Apr 2010 05:49:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:received:in-reply-to
         :references:date:message-id:subject:from:to:content-type;
        bh=e6HvTzkTo9+LJT/o8Y61OeQnMMfoCx9gv6Lw/bPB894=;
        b=JsDLWqWxsDbhFE9xXGOPFMQDpVoNk+t8PKW+RAdEsGtAA8Elb3PoBtgAA7uDNg6wWU
         q08kI9XmSRo0pZAufTB0HpV4VsVmsCxH3bVIm2PixVpLY2UBlEEqRcivQjtasQ0FHVXf
         8R8VTuOthk5r/sj9lCWiBrpN6M49bMN0FrREw=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=rnpCHfi5fHanEDbB+zLJ9MmbvL24MpaNqtWWfTzMn4WHSNfmnYTxDVZw9isHq8XZLO
         VWSG9bag1/XGo9lPPei55aTv6LlIXIyckAtPOUbn00G2U2iNAv1z/HMqxAQivp05fUUf
         VCb1Yu77caSGnBv3PCrTLXTlZoC8Mul7Fekt0=
MIME-Version: 1.0
Received: by 10.204.157.17 with SMTP id z17mr2634151bkw.25.1272286171620;
 Mon,
	26 Apr 2010 05:49:31 -0700 (PDT)
Received: by 10.204.76.68 with HTTP; Mon, 26 Apr 2010 05:49:31 -0700 (PDT)
In-Reply-To: <F6DBE679-90EF-400B-9C67-BC0C68D3AD3A@sonatype.com>
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>
	 <F6DBE679-90EF-400B-9C67-BC0C68D3AD3A@sonatype.com>
Date: Mon, 26 Apr 2010 13:49:31 +0100
Message-ID: <i2i88c1b41004260549heb83d3a0w1be126e3408acc5c@mail.gmail.com>
Subject: Re: Concurrency in m3 - a status report
From: Stephen Connolly <stephen.alan.connolly@gmail.com>
To: Maven Developers List <dev@maven.apache.org>
Content-Type: multipart/alternative; boundary=0015175cb2c84fe66a04852335ea
X-Virus-Checked: Checked by ClamAV on apache.org

--0015175cb2c84fe66a04852335ea
Content-Type: text/plain; charset=ISO-8859-1

On 26 April 2010 13:40, Jason van Zyl <jason@sonatype.com> wrote:

> On Apr 26, 2010, at 7:05 AM, Benjamin Bentmann wrote:
>
> > Stephen Connolly wrote:
> >
> >> ... but each release of m3
> >> would have it's own compatibility info and we would have another state:
> >> unknown
> >>
> >> e.g.
> >>
> >> <thread-safety>
> >>   <plugin groupId="..." artifactId="...">
> >>     <wieve-mode action="ban" versions="...">message</wieve-mode>
> >>     <wieve-mode action="warn" versions="...">message</wieve-mode>
> >>     <wieve-mode action="checked" versions="..."/>
> >>     <parallel-mode action="ban" versions="...">message</paralle-mode>
> >>     <parallel-mode action="warn" versions="...">message</paralle-mode>
> >>     <parallel-mode action="checked"
> versions="...">message</paralle-mode>
> >>   </plugin>
> >> </thread-safety>
> >>
> >> Any plugins not in the list would be "unknown" and the user gets a big
> fat
> >> warning
> >
> > 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.
> >
> > 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.
> >
> > 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?
> >
> > 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
> >
>
> 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.
>
>
This is not an @nothreadsafe annotation I was suggesting, but a @noparallel
annotation

i.e. for the plugin author to mark a mojo as specifically banning parallel
execution

-Stephen


> > "Goal X does not appear to support concurrent execution and might fail
> the build, use parallel building at your own risk."
> >
> >
> > Benjamin
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
>

--0015175cb2c84fe66a04852335ea--