[
http://jira.codehaus.org/browse/MEXEC-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jerome Lacoste updated MEXEC-20:
--------------------------------
Fix Version/s: (was: before-1.1)
1.1-beta-1
> rethink the default thread management
> -------------------------------------
>
> Key: MEXEC-20
> URL: http://jira.codehaus.org/browse/MEXEC-20
> Project: Maven 2.x Exec Plugin
> Issue Type: Improvement
> Affects Versions: before-1.1
> Reporter: Jerome Lacoste
> Assignee: Jerome Lacoste
> Priority: Blocker
> Fix For: 1.1-beta-1
>
>
> Before 1.1 is released I want us to make a proper handling of threads in
> java:exec.
> Today the plugin does the following:
> 1- join non daemon threads
> 2- interrupt remaining threads
> 3- stop() all threads in group
> 1 is OK as that's the condition used by the VM for detecting when to stop().
> But I don't think we should enable 2 and 3 by default, because they don't
> represent what the VM does.
> The whole idea of cleaning up threads after running is because we are running
> the command in the same VM as maven and we don't want these unfinished
> threads to keep running. Thus we're forced to do things that are abnormal
> compared to normal execution.
> So what could we do ?
> I believe that the plugin is mostly used on the command line. In that case,
> not cleaning up is less of a problem.
> One proposed solution is to not perform point 2 and 3 by default and force
> the user to enable a flag to kill those threads.
> Any better idea ?
> See MEXEC-18 and MEXEC-6 for historic and discussions of the original
> implementation of the thread management in 1.1
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
