maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Concurrency in m3 - a status report
Date Mon, 26 Apr 2010 12:49:31 GMT
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
> ----------------------------------------------------------
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message