Embedder vs. System.Diagnostics.Process?

[Wendy Smoak-3]

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

[Shane Isbell]

On Mon, Mar 31, 2008 at 10:51 AM, Wendy Smoak <wsmoak@...> 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 Znamenáček]

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 <wsmoak@...> 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: [phone]* | Fixed Line: [phone]
E-mail: znamenacek@... <mailto:znamenacek@...> | Web:
http://www.cncz.cz

[Wendy Smoak-3]

On Mon, Mar 31, 2008 at 11:12 AM, Shane Isbell <shane.isbell@...> 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

[Pavel Znamenáček]

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 <wsmoak@...> 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: [phone]* | Fixed Line: [phone]
E-mail: znamenacek@... <mailto:znamenacek@...> | Web:
http://www.cncz.cz

[Wendy Smoak-3]

2008/3/31 Pavel Znamenáček <znamenacek@...>:

>     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

[Evan Worley]

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 <wsmoak@...> wrote:

> On Mon, Mar 31, 2008 at 11:12 AM, Shane Isbell <shane.isbell@...>
> 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
>

[bong]

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 <[e-mail]> wrote:

> On Mon, Mar 31, 2008 at 11:12 AM, Shane Isbell <[e-mail]>
> 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

[bong]

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

[Evan Worley]

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 <lagdeppa@...>
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
>

[bong]

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 <[e-mail]>
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
>

[bong]

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


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 <[e-mail]>
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
>

[bong]

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


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 <[e-mail]>
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
>