I would actually prefer for maven to create the visual studio project files rather than visual studio addin creating pom files for several reasons:
On many open source projects I see multiple project files maintained for different versions of visual studio, allowing visual studio files to be generated from pom then it could generate different project files for VS 2005, VS 2008, SharpDevelop, MonoDevelop,
or whatever is desired.
One scenario I have been trying to figure out how to handle cleanly is switching between file references and project references depending if you want to work with binaries or source. We have a few shared projects that are most often referenced using
file references, but when you are debugging an issue sometimes it is useful to import other solution files (File -> Open Solution -> add to project) so that you can easily debug into and navigate between the different projects with resharper,
but after importing the projects you need to update all the references or fix the build order which is a real pain. I was thinking if solution files were generated by maven I could configure the plugin to generate different references depending
on if I want reference project binary or project source code. Perhaps could be generalized some how so that you could also checking the source code for 3rd party libraries like nhibernate and by a line or two in the plugin config have it extract the
source code to a sub folder and create project references as necessary so that you have one solution consisting of all the source you want to debug.
Maven is far more declarative then msbuild so it would be possible to make generate many different versions of the project files (ie one with file references one with project references) with just a single change in the plugin configuration where
as the same does not seem to work in msubild. Although visual studio project files are msbuild files, visual studio will rewrite sections of the build file as it sees fit possibly replacing variables with hard coded paths because user changed something
in property dialog or whatever, and conditionals do not seem to work properlywithin visual studio for some reason (I tried using conditional based on presence of a source directory to switch between itemgroup of projectreferences and itemgroup of file references
but visual studio wouldn't resolve the build order correctly). I have found that tryingto do any non-trivial customization of the visual studio build files to be a disaster and why I started looking into NPanday in the first place.
The addin is great for adding maven artifacts to the project and what not but at the moment it still seems a bit of work to get your path setup properly before you can build from visual studio, I think in general I would prefer not to even include the sln
and csproj files in source control and just run a mvn plugin to generate them after checkout as is done with ellipse and idea.
I certainly agree with the sentiment, and we have an open issue for this: http://npanday.codeplex.com/WorkItem/View.aspx?WorkItemId=10696. The code of the previous version would still be present in the source history as a starting point.
As a general concern, I'd like to ensure NPanday works better with hand-edited POMs (and those generated by archetypes) by reducing the amount of configuration needed for the plugins. While at the moment we have a lot of users taking a "Visual
Studio first" approach, you've highlighted several reasons why a "Maven first" approach makes sense - and both can then be kept in sync via the POM.
One thing to keep in mind is the trend in Java to move away from the "generation" types of mojos towards native integration. If the code to convert a POM to a solution is written in .NET using the MSBuild APIs, it could hopefully be reused from
both a mojo wrapper (for generating from Maven), or as an "Import from Maven..." function in Visual Studio via the Add-in.