You are viewing a plain text version of this content. The canonical link for it is here.
Posted to nmaven-dev@incubator.apache.org by Wendy Smoak <ws...@gmail.com> on 2008/03/31 17:51:07 UTC
Embedder vs. System.Diagnostics.Process?
There is some discussion on NMAVEN-106 [1] about the embedder in a
long-running Jetty process vs. one-off 'mvn' invocations.
I think it needs more discussion before moving to JIRA as an
enhancement request.
One question I have is, what would making that change mean for the
feature that keeps the pom in sync with the solution and .csproj
files?
[1] http://jira.codehaus.org/browse/NMAVEN-106
Thanks,
--
Wendy
Re: Embedder vs. System.Diagnostics.Process?
Posted by bong <la...@exist.com>.
Evan Worley wrote:
>
> Without changing the current implementation, we could use a "keep alive"
> approach to manage the launched process. With this approach the plugin
> would be responsible for sending a keep alive ping to the launched
> process.
> The launched process would kill itself if it didn't receive a ping in a
> specified amount of time. This way, there can be an option in the plugin
> to
> stop the build (which would essentially stop sending keep alive requests).
>
> Just a thought, I've done something similar to manage the life cycle of an
> out of process embedded web server.
>
> -Evan
>
> On Mon, Mar 31, 2008 at 1:23 PM, Wendy Smoak <ws...@gmail.com> wrote:
>
>> On Mon, Mar 31, 2008 at 11:12 AM, Shane Isbell <sh...@gmail.com>
>> wrote:
>>
>> > The VS addin directly handles the modification of the poms,
>> independent
>> of
>> > the maven embedder service, so that part would not be affected by
>> either
>> > solution.
>>
>> Okay, thanks. Back to the original question then. :)
>>
>> One thing that was raised in the JIRA issue is: 'canceling an executed
>> nmaven command in VS'.
>>
>> Leopoldo, are you talking about an individual build, or the ability to
>> stop the Add-in altogether?
>>
>> I'm interested in the latter, since I've noticed that I can't do a
>> command line build after building with the VS Add-in. (Maven
>> complains about files being in use.) There doesn't seem to be a way
>> to stop it without exiting Visual Studio (and then it doesn't always
>> stop... sometimes I have to kill a Java process.)
>>
>> So yes, there are some issues with the separate long-running process,
>> but I'm not yet convinced that discarding it entirely is the way to
>> go.
>>
>> --
>> Wendy
>>
>
>
Using the System Diagnostics.Process in Calling NMaven, once the VS is
exited, by default on windows processes exists its child processes, and I
have confirmed this by exiting VS while running a maven build,
in this way, we won't need to keep communicating with the server just to
know if VS is still running, windows will handle the child process
termination automatically and cleanly
--
View this message in context: http://www.nabble.com/Embedder-vs.-System.Diagnostics.Process--tp16405147p16466116.html
Sent from the nmaven-dev mailing list archive at Nabble.com.
Re: Embedder vs. System.Diagnostics.Process?
Posted by Evan Worley <ev...@gmail.com>.
Without changing the current implementation, we could use a "keep alive"
approach to manage the launched process. With this approach the plugin
would be responsible for sending a keep alive ping to the launched process.
The launched process would kill itself if it didn't receive a ping in a
specified amount of time. This way, there can be an option in the plugin to
stop the build (which would essentially stop sending keep alive requests).
Just a thought, I've done something similar to manage the life cycle of an
out of process embedded web server.
-Evan
On Mon, Mar 31, 2008 at 1:23 PM, Wendy Smoak <ws...@gmail.com> wrote:
> On Mon, Mar 31, 2008 at 11:12 AM, Shane Isbell <sh...@gmail.com>
> wrote:
>
> > The VS addin directly handles the modification of the poms, independent
> of
> > the maven embedder service, so that part would not be affected by
> either
> > solution.
>
> Okay, thanks. Back to the original question then. :)
>
> One thing that was raised in the JIRA issue is: 'canceling an executed
> nmaven command in VS'.
>
> Leopoldo, are you talking about an individual build, or the ability to
> stop the Add-in altogether?
>
> I'm interested in the latter, since I've noticed that I can't do a
> command line build after building with the VS Add-in. (Maven
> complains about files being in use.) There doesn't seem to be a way
> to stop it without exiting Visual Studio (and then it doesn't always
> stop... sometimes I have to kill a Java process.)
>
> So yes, there are some issues with the separate long-running process,
> but I'm not yet convinced that discarding it entirely is the way to
> go.
>
> --
> Wendy
>
Re: Embedder vs. System.Diagnostics.Process?
Posted by Wendy Smoak <ws...@gmail.com>.
On Mon, Mar 31, 2008 at 11:12 AM, Shane Isbell <sh...@gmail.com> wrote:
> The VS addin directly handles the modification of the poms, independent of
> the maven embedder service, so that part would not be affected by either
> solution.
Okay, thanks. Back to the original question then. :)
One thing that was raised in the JIRA issue is: 'canceling an executed
nmaven command in VS'.
Leopoldo, are you talking about an individual build, or the ability to
stop the Add-in altogether?
I'm interested in the latter, since I've noticed that I can't do a
command line build after building with the VS Add-in. (Maven
complains about files being in use.) There doesn't seem to be a way
to stop it without exiting Visual Studio (and then it doesn't always
stop... sometimes I have to kill a Java process.)
So yes, there are some issues with the separate long-running process,
but I'm not yet convinced that discarding it entirely is the way to
go.
--
Wendy
Re: Embedder vs. System.Diagnostics.Process?
Posted by Wendy Smoak <ws...@gmail.com>.
2008/3/31 Pavel Znamenáček <zn...@cncz.cz>:
> sorry I dismissed the affect version of plug-in 0.14. I thought we
> are discussing the trunk features.
In a way we are, since the Visual Studio integration will need to be
added back to trunk at some point.
This is exactly the kind of information we need to hear, so thanks for
jumping in!
--
Wendy
Re: Embedder vs. System.Diagnostics.Process?
Posted by Pavel Znamenáček <zn...@cncz.cz>.
Hi,
sorry I dismissed the affect version of plug-in 0.14. I thought we
are discussing the trunk features.
My fault, sorry once again for may stupid income.
PZn/
Pavel Znamenáček wrote:
> Hi all,
>
> ad 1) Just a small aside of discussion, in this situation of
> embedding the maven to non Java based system, could be this tool helpful?
> http://www.ikvm.net/index.html
> ad 2) How many interactions can jetty handle, I mean how many
> running devenv.exe can be serviced with responses to requests at once?
> It would be probably 1:1, one devenv serviced via one jetty. => Memory
> and network requirements.
> ad 3) I would prefer following requirements from following
> common needs and usage: (Just my opinion and feeling, pleas skip
> irrelevant/stupid needs and requirements to Maven or NMaven)
> Some of needs and usage:
> u1: I spent all day in VS with managing code and the project
> contents with a lot of my own internal project builds in scope of
> solution.
> u2: I use refactoring tools (ReSharper, DevExpress, ...)
> very often which implies actions like renaming the files and some time
> the project also.
> u3: I debug in the unit test often within built and dependent
> assemblies.
> Requirements:
> r1: Memory requirements - my usual devenv.exe process
> occupies about 200MB of memory. How much occupies maven and java? And
> how much all of them together? I think there could be situations where
> more then one devenv.exe will run at once.
> r2: The maven embedder have to be really reflective if you
> really want to embed one.
> r3: The IDEs' add-ins change the content of the project file,
> and I think csproj is not the same as pom.xml. The pom.xml declares
> much more then building rules. I see csproj as a subset of pom.xml.
> r4: Give as ability to generate {cs|vb|js}proj from pom.xml -
> with filled dependencies to other pom.xml or assemblies.
> r5: Give as ability to generate sln for all pom.xml - and I
> use special editor VS to edit, debug and run the projects.
> r6: Give as ability to start VS for pom.xml (modules) of
> generated sln to start working at morning and let us resolve changes
> like back-port into pom.xml at evening.
> r7: If you embed maven, how do the maven distinguish between
> debug and release assemblies?
> r8: Save the maven's position at the best continuum system.
>
> PZn/
>
> Shane Isbell wrote:
>> On Mon, Mar 31, 2008 at 10:51 AM, Wendy Smoak <ws...@gmail.com> wrote:
>>
>>
>>> There is some discussion on NMAVEN-106 [1] about the embedder in a
>>> long-running Jetty process vs. one-off 'mvn' invocations.
>>>
>>> I think it needs more discussion before moving to JIRA as an
>>> enhancement request.
>>>
>>> One question I have is, what would making that change mean for the
>>> feature that keeps the pom in sync with the solution and .csproj
>>> files?
>>>
>>
>>
>> The VS addin directly handles the modification of the poms,
>> independent of
>> the maven embedder service, so that part would not be affected by either
>> solution.
>>
>> Shane
>>
>>
>>> [1] http://jira.codehaus.org/browse/NMAVEN-106
>>>
>>> Thanks,
>>> --
>>> Wendy
>>>
>>>
>>
>>
>
--
**Pavel Znamenacek**
*Software Developer*
**CN Resources International (CZ) a.s.**
Ve Smeckach 20, Prague 1, 110 00
*VoIP Line: +420 234 375 383* | Fixed Line: +420 234 375 183
E-mail: znamenacek@cncz.cz <ma...@cncz.cz> | Web:
http://www.cncz.cz
Re: Embedder vs. System.Diagnostics.Process?
Posted by Pavel Znamenáček <zn...@cncz.cz>.
Hi all,
ad 1) Just a small aside of discussion, in this situation of
embedding the maven to non Java based system, could be this tool helpful?
http://www.ikvm.net/index.html
ad 2) How many interactions can jetty handle, I mean how many running
devenv.exe can be serviced with responses to requests at once? It would
be probably 1:1, one devenv serviced via one jetty. => Memory and
network requirements.
ad 3) I would prefer following requirements from following common
needs and usage: (Just my opinion and feeling, pleas skip
irrelevant/stupid needs and requirements to Maven or NMaven)
Some of needs and usage:
u1: I spent all day in VS with managing code and the project
contents with a lot of my own internal project builds in scope of solution.
u2: I use refactoring tools (ReSharper, DevExpress, ...) very
often which implies actions like renaming the files and some time the
project also.
u3: I debug in the unit test often within built and dependent
assemblies.
Requirements:
r1: Memory requirements - my usual devenv.exe process occupies
about 200MB of memory. How much occupies maven and java? And how much
all of them together? I think there could be situations where more then
one devenv.exe will run at once.
r2: The maven embedder have to be really reflective if you
really want to embed one.
r3: The IDEs' add-ins change the content of the project file,
and I think csproj is not the same as pom.xml. The pom.xml declares much
more then building rules. I see csproj as a subset of pom.xml.
r4: Give as ability to generate {cs|vb|js}proj from pom.xml -
with filled dependencies to other pom.xml or assemblies.
r5: Give as ability to generate sln for all pom.xml - and I
use special editor VS to edit, debug and run the projects.
r6: Give as ability to start VS for pom.xml (modules) of
generated sln to start working at morning and let us resolve changes
like back-port into pom.xml at evening.
r7: If you embed maven, how do the maven distinguish between
debug and release assemblies?
r8: Save the maven's position at the best continuum system.
PZn/
Shane Isbell wrote:
> On Mon, Mar 31, 2008 at 10:51 AM, Wendy Smoak <ws...@gmail.com> wrote:
>
>
>> There is some discussion on NMAVEN-106 [1] about the embedder in a
>> long-running Jetty process vs. one-off 'mvn' invocations.
>>
>> I think it needs more discussion before moving to JIRA as an
>> enhancement request.
>>
>> One question I have is, what would making that change mean for the
>> feature that keeps the pom in sync with the solution and .csproj
>> files?
>>
>
>
> The VS addin directly handles the modification of the poms, independent of
> the maven embedder service, so that part would not be affected by either
> solution.
>
> Shane
>
>
>> [1] http://jira.codehaus.org/browse/NMAVEN-106
>>
>> Thanks,
>> --
>> Wendy
>>
>>
>
>
--
**Pavel Znamenacek**
*Software Developer*
**CN Resources International (CZ) a.s.**
Ve Smeckach 20, Prague 1, 110 00
*VoIP Line: +420 234 375 383* | Fixed Line: +420 234 375 183
E-mail: znamenacek@cncz.cz <ma...@cncz.cz> | Web:
http://www.cncz.cz
Re: Embedder vs. System.Diagnostics.Process?
Posted by Shane Isbell <sh...@gmail.com>.
On Mon, Mar 31, 2008 at 10:51 AM, Wendy Smoak <ws...@gmail.com> wrote:
> There is some discussion on NMAVEN-106 [1] about the embedder in a
> long-running Jetty process vs. one-off 'mvn' invocations.
>
> I think it needs more discussion before moving to JIRA as an
> enhancement request.
>
> One question I have is, what would making that change mean for the
> feature that keeps the pom in sync with the solution and .csproj
> files?
The VS addin directly handles the modification of the poms, independent of
the maven embedder service, so that part would not be affected by either
solution.
Shane
>
>
> [1] http://jira.codehaus.org/browse/NMAVEN-106
>
> Thanks,
> --
> Wendy
>
Re: Embedder vs. System.Diagnostics.Process?
Posted by bong <la...@exist.com>.
There is also a problem when running mvn install in the command line while VS
addin is running and the project is making use of Castles Dynamic Proxy.
check the error below:
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] C:\Documents and
Settings\rlhof\.m2\pab\gac_msil\NMaven.VisualStudio.Addin\0.14-mae
stro-1.5.2-M3__NMaven.VisualStudio\Castle.DynamicProxy.dll (The process
cannot access the
file because it is being used by another process)
we can remove this one by changing this one to Processes because we wont
need it for marshaling the commands sent to the
webservice
bong wrote:
>
> We could stop the process though by calling proc.Kill() to kill running
> child process in the
> OnDisconnection method of NMaven.VisualStudio.Addin.Connect class
>
>
> Evan Worley wrote:
>>
>> I don't believe this is the case if the parent process terminates
>> unexpectedly. Have you tried that scenario? You should be able to make
>> this happen by using the windows task manager to kill the VS process.
>>
>> On Thu, Apr 3, 2008 at 12:03 AM, Leopoldo Agdeppa <la...@exist.com>
>> wrote:
>>
>>> Hello
>>>
>>> Using the System Diagnostics.Process in Calling NMaven, once the VS is
>>> exited, by default on windows processes exists its child processes, and
>>> I
>>> have confirmed this by exiting VS while running a maven build,
>>>
>>> in this way, we won't need to keep communicating with the server just to
>>> know if VS is still running, windows will handle the child process
>>> termination automatically and cleanly
>>>
>>> thanks
>>> bong
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Embedder-vs.-System.Diagnostics.Process--tp16405147p16626733.html
Sent from the nmaven-dev mailing list archive at Nabble.com.
Re: Embedder vs. System.Diagnostics.Process?
Posted by bong <la...@exist.com>.
There is also a problem of Castles Dynamic Proxy DLL when VS addin is used,
we can remove this one by
changing this one to Processes because we wont need it for marshaling the
commands sent to the
webservice
bong wrote:
>
> We could stop the process though by calling proc.Kill() to kill running
> child process in the
> OnDisconnection method of NMaven.VisualStudio.Addin.Connect class
>
>
> Evan Worley wrote:
>>
>> I don't believe this is the case if the parent process terminates
>> unexpectedly. Have you tried that scenario? You should be able to make
>> this happen by using the windows task manager to kill the VS process.
>>
>> On Thu, Apr 3, 2008 at 12:03 AM, Leopoldo Agdeppa <la...@exist.com>
>> wrote:
>>
>>> Hello
>>>
>>> Using the System Diagnostics.Process in Calling NMaven, once the VS is
>>> exited, by default on windows processes exists its child processes, and
>>> I
>>> have confirmed this by exiting VS while running a maven build,
>>>
>>> in this way, we won't need to keep communicating with the server just to
>>> know if VS is still running, windows will handle the child process
>>> termination automatically and cleanly
>>>
>>> thanks
>>> bong
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Embedder-vs.-System.Diagnostics.Process--tp16405147p16626275.html
Sent from the nmaven-dev mailing list archive at Nabble.com.
Re: Embedder vs. System.Diagnostics.Process?
Posted by bong <la...@exist.com>.
We could stop the process though by calling proc.Kill() to kill running child
process in the
OnDisconnection method of NMaven.VisualStudio.Addin.Connect class
Evan Worley wrote:
>
> I don't believe this is the case if the parent process terminates
> unexpectedly. Have you tried that scenario? You should be able to make
> this happen by using the windows task manager to kill the VS process.
>
> On Thu, Apr 3, 2008 at 12:03 AM, Leopoldo Agdeppa <la...@exist.com>
> wrote:
>
>> Hello
>>
>> Using the System Diagnostics.Process in Calling NMaven, once the VS is
>> exited, by default on windows processes exists its child processes, and I
>> have confirmed this by exiting VS while running a maven build,
>>
>> in this way, we won't need to keep communicating with the server just to
>> know if VS is still running, windows will handle the child process
>> termination automatically and cleanly
>>
>> thanks
>> bong
>>
>
>
--
View this message in context: http://www.nabble.com/Embedder-vs.-System.Diagnostics.Process--tp16405147p16485923.html
Sent from the nmaven-dev mailing list archive at Nabble.com.