Importing npanday project into Visual Studio

Sep 23, 2009 at 1:37 PM

I have downloaded and installed the last version of npanday (1.0.2) but I can't get to work the command to generate the solution (http://wsmoak.net/npanday/1.0.2/guide/simple_project.html, step 5).

When I run: "mvn npanday.plugin:NPanday.Plugin.Solution.JavaBinding:Solution", I get:

 

[INFO] Scanning for projects...
[INFO] artifact npanday.plugin:NPanday.Plugin.Solution.JavaBinding: checking for updates from npandaylocal
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] The plugin 'npanday.plugin:NPanday.Plugin.Solution.JavaBinding' does not exist or no valid version could be found
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 second
[INFO] Finished at: Wed Sep 23 10:27:00 GMT-03:00 2009
[INFO] Final Memory: 2M/508M
[INFO] ------------------------------------------------------------------------

 

 

[INFO] Scanning for projects...
[INFO] artifact npanday.plugin:NPanday.Plugin.Solution.JavaBinding: checking for updates from npandaylocal
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] The plugin 'npanday.plugin:NPanday.Plugin.Solution.JavaBinding' does not exist or no valid version could be found
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 second
[INFO] Finished at: Wed Sep 23 10:27:00 GMT-03:00 2009
[INFO] Final Memory: 2M/508M
[INFO] ------------------------------------------------------------------------

I search all the distributions for this plugin, but I didn't find it, so I downloaded the source code (trunk version), and I run the complete build, but it didn't generate this plugin neither.

Looking up deeper into the source code, made me find the missing plugin source code ("trunk\plugins\netplugins\NPanday.Plugin.Solution"), but when I try to install using "mvn clean install" I also get an error ... what I'm missing here?

Thanks in advance (and sorry for my poor english)

 

 

 

Sep 25, 2009 at 1:32 PM

I'm getting the same problem; trying to work it out.

 

Will update if I find a solution.  Wish someone would update the documentation.

Sep 25, 2009 at 1:39 PM

I've found a sollution. It seems that in the process of migrating old code from NMaven, there where some artifacts missings. I had to add the following classes:

 

ExecutionException.cs
Factory.cs
IProjectGenerator.cs
IProjectReference.cs
ProjectGeneratorImpl.cs
ProjectReferenceImpl.cs

ExecutionException.cs

Factory.cs

IProjectGenerator.cs

IProjectReference.cs

ProjectGeneratorImpl.cs

ProjectReferenceImpl.cs

and the following dependencies:

    <dependency> 

      <groupId>Microsoft.Build.Engine</groupId>  

      <artifactId>Microsoft.Build.Engine</artifactId>  

      <type>gac_msil</type>  

      <version>2.0.0.0</version>  

      <classifier>b03f5f7f11d50a3a</classifier> 

    </dependency>  

And build everything again.

Also you have to add this to net-dependencies.xml

  <netDependency>

    <groupId>npanday.plugin</groupId>

    <artifactId>NPanday.Plugin.Solution</artifactId>

    <type>netplugin</type>

  </netDependency>

I will explain deeper later.

 

 

Coordinator
Sep 28, 2009 at 10:11 AM

Hi,

The mvn npanday.plugin:NPanday.Plugin.Solution.JavaBinding:Solution has been removed from 1.0.2, We will update the documentation regarding this one. If you want to start testing out NPanday We suggest that you open Visual Studio and right click on the project and select Generate Solution's Pom Information.

We hope that you get to use NPanday soon,

 

Thanks,

Mar 4, 2010 at 5:16 AM

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.  

Coordinator
Mar 4, 2010 at 11:09 AM
kurtharriger wrote:

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.

Coordinator
Mar 8, 2010 at 2:53 AM

+1 on being able to build on a maven first approach, I think we should start working on issues that would prepare the configuration in the poms to be simpler since at the moment the pom has a lot of configurations involved in them, this is brought about by the VS first approach.